[Kernel-packages] [Bug 1971437] Re: linux-image-5.15.0-27-generic causes Thinkpad T460p to not resume after suspend
I'm happy to report that the problem seems to be gone with the 5.15.0-40-generic kernel. I've been able to suspend and resume two times since booting it. Maybe you should give it a try? If 5.15.0-40 fixes it for you as well, then it probably means this bug can be closed. -- 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/1971437 Title: linux-image-5.15.0-27-generic causes Thinkpad T460p to not resume after suspend Status in linux package in Ubuntu: Confirmed Bug description: After upgrading from Ubuntu 21.10 to Ubuntu 22.04, my Lenovo Thinkpad T460p doesn't wake-up after suspend. The kernel installed was linux- image-5.15.0-27-generic. I downgraded to Linux kernel 5.13.15 and it works fine now. With Ubuntu 21.10, I had linux-image-5.13.15-40-generic kernel and it worked fine, but I've uninstalled it after the upgrade to 22.04. I also tested newer versions like 5.16.x and 5.17.x with the mainline program and they cause the same issue. The issue is that no key nor the power button nor the screen lid wake the laptop with kernel versions superior to Linux 5.13 (5.13.15 I think). It's either a Linux kernel problem, or a compile options mistake. $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 22.04 LTS Release:22.04 Codename: jammy --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu82 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: jack 1283 F pulseaudio CasperMD5CheckResult: unknown CurrentDesktop: LXQt DistroRelease: Ubuntu 22.04 InstallationDate: Installed on 2022-04-06 (27 days ago) InstallationMedia: Lubuntu 21.10 "Impish Indri" - Release amd64 (20211012) MachineType: LENOVO 20FXS09D00 Package: linux (not installed) ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-27-generic root=UUID=11961357-77ee-4aa4-82c2-359cbb8ef64b ro quiet cryptdevice=UUID=08f4ae12-6133-4c63-b78d-d855746c5f26:luks-08f4ae12-6133-4c63-b78d-d855746c5f26 root=/dev/mapper/luks-08f4ae12-6133-4c63-b78d-d855746c5f26 splash vt.handoff=7 ProcVersionSignature: Ubuntu 5.15.0-27.28-generic 5.15.30 RelatedPackageVersions: linux-restricted-modules-5.15.0-27-generic N/A linux-backports-modules-5.15.0-27-generic N/A linux-firmware 20220329.git681281e4-0ubuntu1 Tags: jammy Uname: Linux 5.15.0-27-generic x86_64 UpgradeStatus: Upgraded to jammy on 2022-05-03 (0 days ago) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 07/28/2019 dmi.bios.release: 2.32 dmi.bios.vendor: LENOVO dmi.bios.version: R07ET92W (2.32 ) dmi.board.asset.tag: Not Available dmi.board.name: 20FXS09D00 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40697 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.ec.firmware.release: 1.5 dmi.modalias: dmi:bvnLENOVO:bvrR07ET92W(2.32):bd07/28/2019:br2.32:efr1.5:svnLENOVO:pn20FXS09D00:pvrThinkPadT460p:rvnLENOVO:rn20FXS09D00:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_20FX_BU_Think_FM_ThinkPadT460p: dmi.product.family: ThinkPad T460p dmi.product.name: 20FXS09D00 dmi.product.sku: LENOVO_MT_20FX_BU_Think_FM_ThinkPad T460p dmi.product.version: ThinkPad T460p dmi.sys.vendor: LENOVO --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu82 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: jack 1283 F pulseaudio CasperMD5CheckResult: unknown CurrentDesktop: LXQt DistroRelease: Ubuntu 22.04 InstallationDate: Installed on 2022-04-06 (27 days ago) InstallationMedia: Lubuntu 21.10 "Impish Indri" - Release amd64 (20211012) MachineType: LENOVO 20FXS09D00 Package: linux (not installed) ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-27-generic root=UUID=11961357-77ee-4aa4-82c2-359cbb8ef64b ro quiet cryptdevice=UUID=08f4ae12-6133-4c63-b78d-d855746c5f26:luks-08f4ae12-6133-4c63-b78d-d855746c5f26 root=/dev/mapper/luks-08f4ae12-6133-4c63-b78d-d855746c5f26 splash vt.handoff=7 ProcVersionSignature: Ubuntu 5.15.0-27.28-generic 5.15.30 RelatedPackageVersions: linux-restricted-modules-5.15.0-27-generic N/A linux-backports-modules-5.15.0-27-generic N/A linux-firmware 20220329.git681281e4-0ubuntu1 Tags: jammy Uname: Linux 5.15.0-27-generic x86_64 UpgradeStatus: Upgraded to jammy on 2022-05-03 (0 days ago) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 07/28/2019 dmi.bios.release: 2.32 dmi.bios.vendor: LENOVO dmi.bios.version: R07ET92W (2.32 ) dmi.board.asset.tag: Not Available dmi.board.name: 20FXS09D00 dmi.board
[Kernel-packages] [Bug 1980371] Re: Enable Ethernet controller : Aquantia Corp. Device [1d6a:14c0]
As discussed I have re-targeted the request to the linux-iot kernel. ** Package changed: linux (Ubuntu) => linux-iot (Ubuntu) ** Changed in: linux-iot (Ubuntu Focal) Importance: Undecided => Medium -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-iot in Ubuntu. https://bugs.launchpad.net/bugs/1980371 Title: Enable Ethernet controller : Aquantia Corp. Device [1d6a:14c0] Status in HWE Next: New Status in linux-iot package in Ubuntu: Invalid Status in linux-iot source package in Focal: In Progress Bug description: [Impact] Need to enable Aquantia NIC [1d6a:14c0] for an IoT project. [Fix] This series of patch in v5.8 enable the NIC https://patchwork.ozlabs.org/project/netdev/cover/20200424072729.953-1-irussk...@marvell.com/ [Test] We don't have 10GbE equipment to measure the speed, but it reaches around 1Gb/s in my test environment. $ iperf3 -c 10.102.88.47 Connecting to host 10.102.88.47, port 5201 [ 5] local 10.102.80.195 port 53346 connected to 10.102.88.47 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 115 MBytes 966 Mbits/sec 39293 KBytes [ 5] 1.00-2.00 sec 111 MBytes 933 Mbits/sec 26291 KBytes [ 5] 2.00-3.00 sec 111 MBytes 933 Mbits/sec 26291 KBytes [ 5] 3.00-4.00 sec 112 MBytes 944 Mbits/sec 26291 KBytes [ 5] 4.00-5.00 sec 111 MBytes 933 Mbits/sec 26288 KBytes [ 5] 5.00-6.00 sec 112 MBytes 944 Mbits/sec 26291 KBytes [ 5] 6.00-7.00 sec 111 MBytes 933 Mbits/sec 26293 KBytes [ 5] 7.00-8.00 sec 111 MBytes 933 Mbits/sec 26293 KBytes [ 5] 8.00-9.00 sec 112 MBytes 944 Mbits/sec 26290 KBytes [ 5] 9.00-10.00 sec 111 MBytes 933 Mbits/sec 26291 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.09 GBytes 940 Mbits/sec 273 sender [ 5] 0.00-10.00 sec 1.09 GBytes 937 Mbits/sec receiver [Where problems could occur] The series of patches only affects atlantic NIC, added some new files for new devices, but hard to evaluate other the impacts on other series of atlantic NICs. Checked and applied the necessary "Fixes" and also done suspend/resume test make sure the driver and the system is stable with those commits. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1980371/+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 1967856] Re: Hairpin traffic does not work with centralized NAT gw
** Changed in: linux (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: linux (Ubuntu Impish) Status: Confirmed => Won't Fix ** Changed in: linux (Ubuntu Kinetic) Status: Confirmed => Invalid -- 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/1967856 Title: Hairpin traffic does not work with centralized NAT gw Status in linux package in Ubuntu: Invalid Status in openvswitch package in Ubuntu: Invalid Status in ovn package in Ubuntu: Invalid Status in linux source package in Focal: Confirmed Status in openvswitch source package in Focal: Invalid Status in ovn source package in Focal: Invalid Status in linux source package in Impish: Won't Fix Status in openvswitch source package in Impish: New Status in ovn source package in Impish: New Status in linux source package in Jammy: Confirmed Status in openvswitch source package in Jammy: Invalid Status in ovn source package in Jammy: Invalid Status in linux source package in Kinetic: Invalid Status in openvswitch source package in Kinetic: Invalid Status in ovn source package in Kinetic: Invalid Bug description: If you have two hvs where hv1 is the gateway chassis and you have an instance running on hv2. On instance on hv2 hairpin traffic works for the first session, but not for the next: $ ping -c1 10.78.95.89 PING 10.78.95.89 (10.78.95.89) 56(84) bytes of data. 64 bytes from 10.78.95.89: icmp_seq=1 ttl=62 time=1.07 ms --- 10.78.95.89 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.078/1.078/1.078/0.000 ms $ sudo ovs-appctl -t ovs-vswitchd dpctl/dump-conntrack icmp,orig=(src=10.78.95.89,dst=192.168.0.211,id=7334,type=8,code=0),reply=(src=192.168.0.211,dst=10.78.95.89,id=7334,type=0,code=0),zone=7 icmp,orig=(src=192.168.0.211,dst=10.78.95.89,id=7334,type=8,code=0),reply=(src=10.78.95.89,dst=192.168.0.211,id=7334,type=0,code=0),zone=7 $ ping -c1 10.78.95.89 PING 10.78.95.89 (10.78.95.89) 56(84) bytes of data. --- 10.78.95.89 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms $ sudo ovs-appctl -t ovs-vswitchd dpctl/dump-conntrack icmp,orig=(src=10.78.95.89,dst=192.168.0.211,id=7334,type=8,code=0),reply=(src=192.168.0.211,dst=10.78.95.89,id=7334,type=0,code=0),zone=7 icmp,orig=(src=192.168.0.211,dst=10.78.95.89,id=7334,type=8,code=0),reply=(src=10.78.95.89,dst=192.168.0.211,id=7334,type=0,code=0),zone=7 icmp,orig=(src=192.168.0.211,dst=10.78.95.89,id=7335,type=8,code=0),reply=(src=10.78.95.89,dst=192.168.0.211,id=7335,type=0,code=0),zone=7 We made an attempt at using OVN built with [0], but that did unfortunately not help. If we however revert [1] it works again: $ ping -c1 10.78.95.89 PING 10.78.95.89 (10.78.95.89) 56(84) bytes of data. 64 bytes from 10.78.95.89: icmp_seq=1 ttl=62 time=1.31 ms --- 10.78.95.89 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.318/1.318/1.318/0.000 ms $ sudo ovs-appctl -t ovs-vswitchd dpctl/dump-conntrack icmp,orig=(src=192.168.0.211,dst=10.78.95.89,id=7336,type=8,code=0),reply=(src=10.78.95.89,dst=192.168.0.211,id=7336,type=0,code=0),zone=7 icmp,orig=(src=10.78.95.89,dst=192.168.0.211,id=7336,type=8,code=0),reply=(src=192.168.0.211,dst=10.78.95.89,id=7336,type=0,code=0),zone=7 icmp,orig=(src=10.78.95.89,dst=192.168.0.211,id=7336,type=8,code=0),reply=(src=192.168.0.211,dst=10.78.95.89,id=7336,type=0,code=0),zone=1 $ ping -c1 10.78.95.89 PING 10.78.95.89 (10.78.95.89) 56(84) bytes of data. 64 bytes from 10.78.95.89: icmp_seq=1 ttl=62 time=0.307 ms --- 10.78.95.89 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.307/0.307/0.307/0.000 ms $ sudo ovs-appctl -t ovs-vswitchd dpctl/dump-conntrack icmp,orig=(src=10.78.95.89,dst=192.168.0.211,id=7337,type=8,code=0),reply=(src=192.168.0.211,dst=10.78.95.89,id=7337,type=0,code=0),zone=7 icmp,orig=(src=10.78.95.89,dst=192.168.0.211,id=7337,type=8,code=0),reply=(src=192.168.0.211,dst=10.78.95.89,id=7337,type=0,code=0),zone=1 icmp,orig=(src=192.168.0.211,dst=10.78.95.89,id=7337,type=8,code=0),reply=(src=10.78.95.89,dst=192.168.0.211,id=7337,type=0,code=0),zone=7 icmp,orig=(src=192.168.0.211,dst=10.78.95.89,id=7336,type=8,code=0),reply=(src=10.78.95.89,dst=192.168.0.211,id=7336,type=0,code=0),zone=7 icmp,orig=(src=10.78.95.89,dst=192.168.0.211,id=7336,type=8,code=0),reply=(src=192.168.0.211,dst=10.78.95.89,id=7336,type=0,code=0),zone=7 icmp,orig=(src=10.78.95.89,dst=192.168.0.211,id=7336,type=8,code=0),reply=(src=192.168.0.211,dst=10.78.95.89,id=7336,type=0,code=0),zone=1 0: https://patchwork.ozlabs.org/project/ovn/patch/20220401175516.2139179-1-mmich...@redhat.com/ 1: https://github.com/ovn-org/ovn/com
[Kernel-packages] [Bug 1981070] [NEW] memcg_* from ubuntu_ltp_controllers fails on Focal 5.15 with mmap (Invalid argument)
Public bug reported: Testcases memcg_failcnt|memcg_max_usage_in_bytes|memcg_subgroup_charge|memcg_usage_in_byte from ubuntu_ltp_controllers are failing with focal/linux-lowlatency-5.15 5.15.0-41.44~20.04.1 flavor lowlatency-64k. memcg_failcnt 1 TINFO: timeout per run is 0h 5m 0s memcg_failcnt 1 TINFO: set /dev/memcg/memory.use_hierarchy to 0 failed memcg_failcnt 1 TINFO: Setting shmmax memcg_failcnt 1 TINFO: Running memcg_process --mmap-anon -s 0 memcg_failcnt 1 TPASS: memory.failcnt is 36, > 0 as expected memcg_failcnt 2 TINFO: Running memcg_process --mmap-file -s 0 memcg_process: mmap(file) failed: Invalid argument memcg_failcnt 2 TFAIL: memory.failcnt is 0, <= 0 expected memcg_failcnt 3 TINFO: Running memcg_process --shm -s 0 memcg_failcnt 3 TPASS: memory.failcnt is 36, > 0 as expected memcg_failcnt 4 TINFO: AppArmor enabled, this may affect test results memcg_failcnt 4 TINFO: it can be disabled with TST_DISABLE_APPARMOR=1 (requires super/root) memcg_failcnt 4 TINFO: loaded AppArmor profiles: none This doesn't seem to be a regression as this test is failing on other combinations of architectures/flavors with bug 1949532. ** Affects: ubuntu-kernel-tests Importance: Undecided Status: New ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Affects: linux (Ubuntu Jammy) Importance: Undecided Status: Confirmed ** Also affects: linux (Ubuntu) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Jammy) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Jammy) Status: New => Confirmed ** Summary changed: - memcg_failcnt from ubuntu_ltp_controllers fails on Focal 5.15 + memcg_failcnt/memcg_max_usage_in_bytes from ubuntu_ltp_controllers fails on Focal 5.15 ** Summary changed: - memcg_failcnt/memcg_max_usage_in_bytes from ubuntu_ltp_controllers fails on Focal 5.15 + memcg_* from ubuntu_ltp_controllers fails on Focal 5.15 with mmap (Invalid argument) ** Description changed: - ubuntu_ltp_controllers.memcg_failcnt is failing with focal/linux- - lowlatency-5.15 5.15.0-41.44~20.04.1 flavor lowlatency-64k. + Testcases + memcg_failcnt|memcg_max_usage_in_bytes|memcg_subgroup_charge|memcg_usage_in_byte + from ubuntu_ltp_controllers are failing with focal/linux-lowlatency-5.15 + 5.15.0-41.44~20.04.1 flavor lowlatency-64k. memcg_failcnt 1 TINFO: timeout per run is 0h 5m 0s memcg_failcnt 1 TINFO: set /dev/memcg/memory.use_hierarchy to 0 failed memcg_failcnt 1 TINFO: Setting shmmax memcg_failcnt 1 TINFO: Running memcg_process --mmap-anon -s 0 memcg_failcnt 1 TPASS: memory.failcnt is 36, > 0 as expected memcg_failcnt 2 TINFO: Running memcg_process --mmap-file -s 0 memcg_process: mmap(file) failed: Invalid argument memcg_failcnt 2 TFAIL: memory.failcnt is 0, <= 0 expected memcg_failcnt 3 TINFO: Running memcg_process --shm -s 0 memcg_failcnt 3 TPASS: memory.failcnt is 36, > 0 as expected memcg_failcnt 4 TINFO: AppArmor enabled, this may affect test results memcg_failcnt 4 TINFO: it can be disabled with TST_DISABLE_APPARMOR=1 (requires super/root) memcg_failcnt 4 TINFO: loaded AppArmor profiles: none - Summary: - passed 2 - failed 1 - broken 0 - skipped 0 - warnings 0 - This doesn't seem to be a regression as this test is failing on other combinations of architectures/flavors with bug 1949532. -- 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/1981070 Title: memcg_* from ubuntu_ltp_controllers fails on Focal 5.15 with mmap (Invalid argument) Status in ubuntu-kernel-tests: New Status in linux package in Ubuntu: New Status in linux source package in Jammy: Confirmed Bug description: Testcases memcg_failcnt|memcg_max_usage_in_bytes|memcg_subgroup_charge|memcg_usage_in_byte from ubuntu_ltp_controllers are failing with focal/linux- lowlatency-5.15 5.15.0-41.44~20.04.1 flavor lowlatency-64k. memcg_failcnt 1 TINFO: timeout per run is 0h 5m 0s memcg_failcnt 1 TINFO: set /dev/memcg/memory.use_hierarchy to 0 failed memcg_failcnt 1 TINFO: Setting shmmax memcg_failcnt 1 TINFO: Running memcg_process --mmap-anon -s 0 memcg_failcnt 1 TPASS: memory.failcnt is 36, > 0 as expected memcg_failcnt 2 TINFO: Running memcg_process --mmap-file -s 0 memcg_process: mmap(file) failed: Invalid argument memcg_failcnt 2 TFAIL: memory.failcnt is 0, <= 0 expected memcg_failcnt 3 TINFO: Running memcg_process --shm -s 0 memcg_failcnt 3 TPASS: memory.failcnt is 36, > 0 as expected memcg_failcnt 4 TINFO: AppArmor enabled, this may affect test results memcg_failcnt 4 TINFO: it can be disabled with TST_DISABLE_APPARMOR=1 (requires super/root) memcg_failcnt 4 TINFO: loaded AppArmor profiles: none This doesn't seem to be a regression as this test is failing on other combinations of architectures/flavors with bug 1949532. To manage notifica
[Kernel-packages] [Bug 1981069] [NEW] test_060_nx in ubuntu_qrt_kernel_security failed on B-gke-5.4 since 5.4.0-1071-gke
Public bug reported: Test failed since 5.4.0-1071.76~18.04.3-gke (works ok with 5.4.0-1068-gke) $ sudo python2 ./test-kernel-security.py -v KernelSecurityTest.test_060_nx Running test: './test-kernel-security.py' distro: 'Ubuntu 18.04' kernel: '5.4.0-1071.76~18.04.3 (Ubuntu 5.4.0-1071.76~18.04.3-gke 5.4.181)' arch: 'amd64' uid: 0/0 SUDO_USER: 'google') test_060_nx (__main__.KernelSecurityTest) NX bit is working ... FAIL == FAIL: test_060_nx (__main__.KernelSecurityTest) NX bit is working -- Traceback (most recent call last): File "./test-kernel-security.py", line 575, in test_060_nx self.assertShellExitEquals(rie_expected, ["./nx-test-rie", "data"]) File "/home/google/autotest/client/tmp/ubuntu_qrt_kernel_security/src/qa-regression-testing/scripts/testlib.py", line 1203, in assertShellExitEquals self.assertEqual(expected, rc, msg + result + report) AssertionError: Got exit code -11, expected 0 Command: './nx-test-rie', 'data' Output: rodata:0x55f37cf22098 data: 0x55f37d123010 bss: 0x55f37d133040 brk: 0x55f37edd7270 rw:0x7f9b635da000 rwx: 0x7f9b635d9000 stack: 0x7ffd6cde4b90 Dump of /proc/self/maps: 55f37cf21000-55f37cf23000 r-xp 08:01 272969 /home/google/autotest/client/tmp/ubuntu_qrt_kernel_security/src/qa-regression-testing/scripts/kernel-security/nx/nx-test-rie 55f37d122000-55f37d123000 r--p 1000 08:01 272969 /home/google/autotest/client/tmp/ubuntu_qrt_kernel_security/src/qa-regression-testing/scripts/kernel-security/nx/nx-test-rie 55f37d123000-55f37d124000 rw-p 2000 08:01 272969 /home/google/autotest/client/tmp/ubuntu_qrt_kernel_security/src/qa-regression-testing/scripts/kernel-security/nx/nx-test-rie 55f37d124000-55f37d134000 rw-p 00:00 0 55f37edd6000-55f37edf7000 rw-p 00:00 0 [heap] 7f9b62fc1000-7f9b631a8000 r-xp 08:01 2245 /lib/x86_64-linux-gnu/libc-2.27.so 7f9b631a8000-7f9b633a8000 ---p 001e7000 08:01 2245 /lib/x86_64-linux-gnu/libc-2.27.so 7f9b633a8000-7f9b633ac000 r--p 001e7000 08:01 2245 /lib/x86_64-linux-gnu/libc-2.27.so 7f9b633ac000-7f9b633ae000 rw-p 001eb000 08:01 2245 /lib/x86_64-linux-gnu/libc-2.27.so 7f9b633ae000-7f9b633b2000 rw-p 00:00 0 7f9b633b2000-7f9b633db000 r-xp 08:01 2240 /lib/x86_64-linux-gnu/ld-2.27.so 7f9b635cf000-7f9b635d1000 rw-p 00:00 0 7f9b635d9000-7f9b635da000 rwxp 00:00 0 7f9b635da000-7f9b635db000 rw-p 00:00 0 7f9b635db000-7f9b635dc000 r--p 00029000 08:01 2240 /lib/x86_64-linux-gnu/ld-2.27.so 7f9b635dc000-7f9b635dd000 rw-p 0002a000 08:01 2240 /lib/x86_64-linux-gnu/ld-2.27.so 7f9b635dd000-7f9b635de000 rw-p 00:00 0 7ffd6cdc6000-7ffd6cde7000 rwxp 00:00 0 [stack] 7ffd6cdfa000-7ffd6cdfd000 r--p 00:00 0 [vvar] 7ffd6cdfd000-7ffd6cdfe000 r-xp 00:00 0 [vdso] ff60-ff601000 --xp 00:00 0 [vsyscall] Attempting to execute function at 0x55f37d123010 If this program seg-faults, the region was enforced as non-executable... -- Ran 1 test in 0.880s FAILED (failures=1) ** Affects: qa-regression-testing Importance: Undecided Status: New ** Affects: ubuntu-kernel-tests Importance: Undecided Status: New ** Affects: linux-gke (Ubuntu) Importance: Undecided Status: New ** Tags: sru-20220620 ubuntu-qrt-kernel-security ** Also affects: linux-gke (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-gke in Ubuntu. https://bugs.launchpad.net/bugs/1981069 Title: test_060_nx in ubuntu_qrt_kernel_security failed on B-gke-5.4 since 5.4.0-1071-gke Status in QA Regression Testing: New Status in ubuntu-kernel-tests: New Status in linux-gke package in Ubuntu: New Bug description: Test failed since 5.4.0-1071.76~18.04.3-gke (works ok with 5.4.0-1068-gke) $ sudo python2 ./test-kernel-security.py -v KernelSecurityTest.test_060_nx Running test: './test-kernel-security.py' distro: 'Ubuntu 18.04' kernel: '5.4.0-1071.76~18.04.3 (Ubuntu 5.4.0-1071.76~18.04.3-gke 5.4.181)' arch: 'amd64' uid: 0/0 SUDO_USER: 'google') test_060_nx (__main__.KernelSecurityTest) NX bit is working ... FAIL == FAIL: test_060_nx (__main__.KernelSecurityTest) NX bit is working -- Traceback
[Kernel-packages] [Bug 1981069] Re: test_060_nx in ubuntu_qrt_kernel_security failed on B-gke-5.4 since 5.4.0-1071-gke
Similar bug reported for F-gcp-fips - bug 1968841 Maybe this commit need to be expand with -gke? https://git.launchpad.net/qa-regression-testing/commit/?id=00e4e841efcad9d0a2dee19283ff0aeb1c6f9fe5 ** Tags added: ubuntu-qrt-kernel-security ** Tags added: sru-20220620 ** Also affects: qa-regression-testing Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-gke in Ubuntu. https://bugs.launchpad.net/bugs/1981069 Title: test_060_nx in ubuntu_qrt_kernel_security failed on B-gke-5.4 since 5.4.0-1071-gke Status in QA Regression Testing: New Status in ubuntu-kernel-tests: New Status in linux-gke package in Ubuntu: New Bug description: Test failed since 5.4.0-1071.76~18.04.3-gke (works ok with 5.4.0-1068-gke) $ sudo python2 ./test-kernel-security.py -v KernelSecurityTest.test_060_nx Running test: './test-kernel-security.py' distro: 'Ubuntu 18.04' kernel: '5.4.0-1071.76~18.04.3 (Ubuntu 5.4.0-1071.76~18.04.3-gke 5.4.181)' arch: 'amd64' uid: 0/0 SUDO_USER: 'google') test_060_nx (__main__.KernelSecurityTest) NX bit is working ... FAIL == FAIL: test_060_nx (__main__.KernelSecurityTest) NX bit is working -- Traceback (most recent call last): File "./test-kernel-security.py", line 575, in test_060_nx self.assertShellExitEquals(rie_expected, ["./nx-test-rie", "data"]) File "/home/google/autotest/client/tmp/ubuntu_qrt_kernel_security/src/qa-regression-testing/scripts/testlib.py", line 1203, in assertShellExitEquals self.assertEqual(expected, rc, msg + result + report) AssertionError: Got exit code -11, expected 0 Command: './nx-test-rie', 'data' Output: rodata:0x55f37cf22098 data: 0x55f37d123010 bss: 0x55f37d133040 brk: 0x55f37edd7270 rw:0x7f9b635da000 rwx: 0x7f9b635d9000 stack: 0x7ffd6cde4b90 Dump of /proc/self/maps: 55f37cf21000-55f37cf23000 r-xp 08:01 272969 /home/google/autotest/client/tmp/ubuntu_qrt_kernel_security/src/qa-regression-testing/scripts/kernel-security/nx/nx-test-rie 55f37d122000-55f37d123000 r--p 1000 08:01 272969 /home/google/autotest/client/tmp/ubuntu_qrt_kernel_security/src/qa-regression-testing/scripts/kernel-security/nx/nx-test-rie 55f37d123000-55f37d124000 rw-p 2000 08:01 272969 /home/google/autotest/client/tmp/ubuntu_qrt_kernel_security/src/qa-regression-testing/scripts/kernel-security/nx/nx-test-rie 55f37d124000-55f37d134000 rw-p 00:00 0 55f37edd6000-55f37edf7000 rw-p 00:00 0 [heap] 7f9b62fc1000-7f9b631a8000 r-xp 08:01 2245 /lib/x86_64-linux-gnu/libc-2.27.so 7f9b631a8000-7f9b633a8000 ---p 001e7000 08:01 2245 /lib/x86_64-linux-gnu/libc-2.27.so 7f9b633a8000-7f9b633ac000 r--p 001e7000 08:01 2245 /lib/x86_64-linux-gnu/libc-2.27.so 7f9b633ac000-7f9b633ae000 rw-p 001eb000 08:01 2245 /lib/x86_64-linux-gnu/libc-2.27.so 7f9b633ae000-7f9b633b2000 rw-p 00:00 0 7f9b633b2000-7f9b633db000 r-xp 08:01 2240 /lib/x86_64-linux-gnu/ld-2.27.so 7f9b635cf000-7f9b635d1000 rw-p 00:00 0 7f9b635d9000-7f9b635da000 rwxp 00:00 0 7f9b635da000-7f9b635db000 rw-p 00:00 0 7f9b635db000-7f9b635dc000 r--p 00029000 08:01 2240 /lib/x86_64-linux-gnu/ld-2.27.so 7f9b635dc000-7f9b635dd000 rw-p 0002a000 08:01 2240 /lib/x86_64-linux-gnu/ld-2.27.so 7f9b635dd000-7f9b635de000 rw-p 00:00 0 7ffd6cdc6000-7ffd6cde7000 rwxp 00:00 0 [stack] 7ffd6cdfa000-7ffd6cdfd000 r--p 00:00 0 [vvar] 7ffd6cdfd000-7ffd6cdfe000 r-xp 00:00 0 [vdso] ff60-ff601000 --xp 00:00 0 [vsyscall] Attempting to execute function at 0x55f37d123010 If this program seg-faults, the region was enforced as non-executable... -- Ran 1 test in 0.880s FAILED (failures=1) To manage notifications about this bug go to: https://bugs.launchpad.net/qa-regression-testing/+bug/1981069/+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 1981070] Missing required logs.
This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window: apport-collect 1981070 and then change the status of the bug to 'Confirmed'. If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'. This change has been made by an automated script, maintained by the Ubuntu Kernel Team. ** Changed in: linux (Ubuntu) Status: New => Incomplete -- 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/1981070 Title: memcg_* from ubuntu_ltp_controllers fails on Focal 5.15 with mmap (Invalid argument) Status in ubuntu-kernel-tests: New Status in linux package in Ubuntu: Incomplete Status in linux source package in Jammy: Confirmed Bug description: Testcases memcg_failcnt|memcg_max_usage_in_bytes|memcg_subgroup_charge|memcg_usage_in_byte from ubuntu_ltp_controllers are failing with focal/linux- lowlatency-5.15 5.15.0-41.44~20.04.1 flavor lowlatency-64k. memcg_failcnt 1 TINFO: timeout per run is 0h 5m 0s memcg_failcnt 1 TINFO: set /dev/memcg/memory.use_hierarchy to 0 failed memcg_failcnt 1 TINFO: Setting shmmax memcg_failcnt 1 TINFO: Running memcg_process --mmap-anon -s 0 memcg_failcnt 1 TPASS: memory.failcnt is 36, > 0 as expected memcg_failcnt 2 TINFO: Running memcg_process --mmap-file -s 0 memcg_process: mmap(file) failed: Invalid argument memcg_failcnt 2 TFAIL: memory.failcnt is 0, <= 0 expected memcg_failcnt 3 TINFO: Running memcg_process --shm -s 0 memcg_failcnt 3 TPASS: memory.failcnt is 36, > 0 as expected memcg_failcnt 4 TINFO: AppArmor enabled, this may affect test results memcg_failcnt 4 TINFO: it can be disabled with TST_DISABLE_APPARMOR=1 (requires super/root) memcg_failcnt 4 TINFO: loaded AppArmor profiles: none This doesn't seem to be a regression as this test is failing on other combinations of architectures/flavors with bug 1949532. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1981070/+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 1981069] Re: test_060_nx in ubuntu_qrt_kernel_security failed on B-gke-5.4 since 5.4.0-1071-gke
** Description changed: - Test failed since 5.4.0-1071.76~18.04.3-gke (works ok with + Test failed since 5.4.0-1071.76~18.04.3-gke AMD64 (works ok with 5.4.0-1068-gke) $ sudo python2 ./test-kernel-security.py -v KernelSecurityTest.test_060_nx Running test: './test-kernel-security.py' distro: 'Ubuntu 18.04' kernel: '5.4.0-1071.76~18.04.3 (Ubuntu 5.4.0-1071.76~18.04.3-gke 5.4.181)' arch: 'amd64' uid: 0/0 SUDO_USER: 'google') test_060_nx (__main__.KernelSecurityTest) NX bit is working ... FAIL == FAIL: test_060_nx (__main__.KernelSecurityTest) NX bit is working -- Traceback (most recent call last): - File "./test-kernel-security.py", line 575, in test_060_nx - self.assertShellExitEquals(rie_expected, ["./nx-test-rie", "data"]) - File "/home/google/autotest/client/tmp/ubuntu_qrt_kernel_security/src/qa-regression-testing/scripts/testlib.py", line 1203, in assertShellExitEquals - self.assertEqual(expected, rc, msg + result + report) + File "./test-kernel-security.py", line 575, in test_060_nx + self.assertShellExitEquals(rie_expected, ["./nx-test-rie", "data"]) + File "/home/google/autotest/client/tmp/ubuntu_qrt_kernel_security/src/qa-regression-testing/scripts/testlib.py", line 1203, in assertShellExitEquals + self.assertEqual(expected, rc, msg + result + report) AssertionError: Got exit code -11, expected 0 Command: './nx-test-rie', 'data' Output: rodata:0x55f37cf22098 data: 0x55f37d123010 bss: 0x55f37d133040 brk: 0x55f37edd7270 rw:0x7f9b635da000 rwx: 0x7f9b635d9000 stack: 0x7ffd6cde4b90 Dump of /proc/self/maps: 55f37cf21000-55f37cf23000 r-xp 08:01 272969 /home/google/autotest/client/tmp/ubuntu_qrt_kernel_security/src/qa-regression-testing/scripts/kernel-security/nx/nx-test-rie 55f37d122000-55f37d123000 r--p 1000 08:01 272969 /home/google/autotest/client/tmp/ubuntu_qrt_kernel_security/src/qa-regression-testing/scripts/kernel-security/nx/nx-test-rie 55f37d123000-55f37d124000 rw-p 2000 08:01 272969 /home/google/autotest/client/tmp/ubuntu_qrt_kernel_security/src/qa-regression-testing/scripts/kernel-security/nx/nx-test-rie - 55f37d124000-55f37d134000 rw-p 00:00 0 + 55f37d124000-55f37d134000 rw-p 00:00 0 55f37edd6000-55f37edf7000 rw-p 00:00 0 [heap] 7f9b62fc1000-7f9b631a8000 r-xp 08:01 2245 /lib/x86_64-linux-gnu/libc-2.27.so 7f9b631a8000-7f9b633a8000 ---p 001e7000 08:01 2245 /lib/x86_64-linux-gnu/libc-2.27.so 7f9b633a8000-7f9b633ac000 r--p 001e7000 08:01 2245 /lib/x86_64-linux-gnu/libc-2.27.so 7f9b633ac000-7f9b633ae000 rw-p 001eb000 08:01 2245 /lib/x86_64-linux-gnu/libc-2.27.so - 7f9b633ae000-7f9b633b2000 rw-p 00:00 0 + 7f9b633ae000-7f9b633b2000 rw-p 00:00 0 7f9b633b2000-7f9b633db000 r-xp 08:01 2240 /lib/x86_64-linux-gnu/ld-2.27.so - 7f9b635cf000-7f9b635d1000 rw-p 00:00 0 - 7f9b635d9000-7f9b635da000 rwxp 00:00 0 - 7f9b635da000-7f9b635db000 rw-p 00:00 0 + 7f9b635cf000-7f9b635d1000 rw-p 00:00 0 + 7f9b635d9000-7f9b635da000 rwxp 00:00 0 + 7f9b635da000-7f9b635db000 rw-p 00:00 0 7f9b635db000-7f9b635dc000 r--p 00029000 08:01 2240 /lib/x86_64-linux-gnu/ld-2.27.so 7f9b635dc000-7f9b635dd000 rw-p 0002a000 08:01 2240 /lib/x86_64-linux-gnu/ld-2.27.so - 7f9b635dd000-7f9b635de000 rw-p 00:00 0 + 7f9b635dd000-7f9b635de000 rw-p 00:00 0 7ffd6cdc6000-7ffd6cde7000 rwxp 00:00 0 [stack] 7ffd6cdfa000-7ffd6cdfd000 r--p 00:00 0 [vvar] 7ffd6cdfd000-7ffd6cdfe000 r-xp 00:00 0 [vdso] ff60-ff601000 --xp 00:00 0 [vsyscall] Attempting to execute function at 0x55f37d123010 If this program seg-faults, the region was enforced as non-executable... - -- Ran 1 test in 0.880s FAILED (failures=1) + + Notet that this issue does not exist on B-gkeop-5.4 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-gke in Ubuntu. https://bugs.launchpad.net/bugs/1981069 Title: test_060_nx in ubuntu_qrt_kernel_security failed on B-gke-5.4 since 5.4.0-1071-gke Status in QA Regression Testing: New Status in ubuntu-kernel-tests: New Status in linux-gke package in Ubuntu: New Bug description: Test failed since 5.4.0-1071.76~18.04.3-gke AMD64 (works ok with 5.4.0-1068-gke) $ sudo python2 ./test-kernel-security
[Kernel-packages] [Bug 1981074] [NEW] Drivers with unsatisfied dependencies on the Allwinner D1
Public bug reported: [Impact] * The drivers for the display engine, crypto acceleration and USB don't probe because of missing dependencies. [Test Plan] * Boot the kernel in linux-image-5.17.0-1002-allwinner and see /sys/kerne/debug/devices_deferred [Where problems could occur] * Fixing this may introduce now bugs if the now probing drivers turn out to be buggy. ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- 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/1981074 Title: Drivers with unsatisfied dependencies on the Allwinner D1 Status in linux package in Ubuntu: New Bug description: [Impact] * The drivers for the display engine, crypto acceleration and USB don't probe because of missing dependencies. [Test Plan] * Boot the kernel in linux-image-5.17.0-1002-allwinner and see /sys/kerne/debug/devices_deferred [Where problems could occur] * Fixing this may introduce now bugs if the now probing drivers turn out to be buggy. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1981074/+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 1981074] Missing required logs.
This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window: apport-collect 1981074 and then change the status of the bug to 'Confirmed'. If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'. This change has been made by an automated script, maintained by the Ubuntu Kernel Team. ** Changed in: linux (Ubuntu) Status: New => Incomplete -- 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/1981074 Title: Drivers with unsatisfied dependencies on the Allwinner D1 Status in linux package in Ubuntu: Incomplete Bug description: [Impact] * The drivers for the display engine, crypto acceleration and USB don't probe because of missing dependencies. [Test Plan] * Boot the kernel in linux-image-5.17.0-1002-allwinner and see /sys/kerne/debug/devices_deferred [Where problems could occur] * Fixing this may introduce now bugs if the now probing drivers turn out to be buggy. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1981074/+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 1980861] Re: Please enable CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU
I'm hoping to look into the effects of MULTI_PERCPU on the smaller Pi platforms (in particular the Pi Zero 2 and 3A+ which each have 512MB of RAM and, with the arm64 arch, typically have ~250MB free at runtime). Unfortunately building a local version of the linux-raspi package (just naively with sbuild) has thus far defeated me, but if I can get a version with the relevant config I'll run through some tests. -- 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/1980861 Title: Please enable CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU Status in Snappy: New Status in linux package in Ubuntu: Incomplete Bug description: The snapd/desktop/advocacy team are investigating the startup performance of running snaps. While doing this and comparing various distros (fedora, opensuse, ubuntu) on Igors reference hardware we noticed that fedora is substantially faster at starting snaps. After some research it turns out that they use the CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU=y option when we use CONFIG_SQUASHFS_DECOMP_SINGLE. I build^Whacked a test kernel in my ppa:mvo/tmp PPA that just changes this one option (https://paste.ubuntu.com/p/NvS4GQjnSp/) and with that the first run firefox startup went from 15s to 6s (!) on Igors reference hardware. Given the dramatic performance improvements we would like to get this option switched. However we need to be careful and double check that the results from https://bugs.launchpad.net/snappy/+bug/1636847 are no longer an issue - back in 2016 the kernel team swtich to _DECOMP_SINGLE because just mounting a snap would use up 131Mb or memory(!). To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1980861/+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 1981075] [NEW] ubuntu_kernel_selftests.net:fib_nexthops.sh times out on riscv
Public bug reported: net:fib_nexthops.sh times out on riscv kernels 12284 12:09:41 DEBUG| [stdout] # 12285 12:09:41 DEBUG| [stdout] # IPv6 runtime resilient nexthop group torture 12286 12:09:41 DEBUG| [stdout] # 12287 12:14:40 INFO | Timer expired (1800 sec.), nuking pid 43387 would be nice to possibly increase timer on riscv, as otherwise the test seems to be running ok. ** Affects: ubuntu-kernel-tests Importance: Undecided Status: New ** Affects: linux-riscv (Ubuntu) Importance: Undecided Status: Confirmed ** Affects: linux-riscv (Ubuntu Jammy) Importance: Undecided Status: Confirmed ** Tags: 5.15 jammy net riscv64 ubuntu-kernel-selftests ** Also affects: linux-riscv (Ubuntu) Importance: Undecided Status: New ** Also affects: linux-riscv (Ubuntu Jammy) Importance: Undecided Status: New ** Changed in: linux-riscv (Ubuntu) Status: New => Confirmed ** Changed in: linux-riscv (Ubuntu Jammy) Status: New => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-riscv in Ubuntu. https://bugs.launchpad.net/bugs/1981075 Title: ubuntu_kernel_selftests.net:fib_nexthops.sh times out on riscv Status in ubuntu-kernel-tests: New Status in linux-riscv package in Ubuntu: Confirmed Status in linux-riscv source package in Jammy: Confirmed Bug description: net:fib_nexthops.sh times out on riscv kernels 12284 12:09:41 DEBUG| [stdout] # 12285 12:09:41 DEBUG| [stdout] # IPv6 runtime resilient nexthop group torture 12286 12:09:41 DEBUG| [stdout] # 12287 12:14:40 INFO | Timer expired (1800 sec.), nuking pid 43387 would be nice to possibly increase timer on riscv, as otherwise the test seems to be running ok. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1981075/+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 1981075] Re: ubuntu_kernel_selftests.net:fib_nexthops.sh times out on riscv
** Changed in: ubuntu-kernel-tests Assignee: (unassigned) => Po-Hsu Lin (cypressyew) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-riscv in Ubuntu. https://bugs.launchpad.net/bugs/1981075 Title: ubuntu_kernel_selftests.net:fib_nexthops.sh times out on riscv Status in ubuntu-kernel-tests: New Status in linux-riscv package in Ubuntu: Confirmed Status in linux-riscv source package in Jammy: Confirmed Bug description: net:fib_nexthops.sh times out on riscv kernels 12284 12:09:41 DEBUG| [stdout] # 12285 12:09:41 DEBUG| [stdout] # IPv6 runtime resilient nexthop group torture 12286 12:09:41 DEBUG| [stdout] # 12287 12:14:40 INFO | Timer expired (1800 sec.), nuking pid 43387 would be nice to possibly increase timer on riscv, as otherwise the test seems to be running ok. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1981075/+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 1981078] [NEW] [pi-kernel] Please set CONFIG_RTC_DRV_DS1307=y
Public bug reported: We recently got a bugreport from a user who uses a PI with an external RTC. The chips is a ds3231. The driver for this is currently compiled as a module. Doing RTC as a module is unfortunately broken in the general case today (see https://github.com/systemd/systemd/issues/17737 and https://forum.snapcraft.io/t/adding-ubuntu-core-fails-on-first-boot- with-rtc-is-present/30391/15 for details). Until a more general fix is available I would like to ask to just compile CONFIG_RTC_DRV_DS1307=y into the kernel that should cover a lot of popular chips and we already build CONFIG_RTC_DRV_DS1307_CENTURY=y ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- 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/1981078 Title: [pi-kernel] Please set CONFIG_RTC_DRV_DS1307=y Status in linux package in Ubuntu: New Bug description: We recently got a bugreport from a user who uses a PI with an external RTC. The chips is a ds3231. The driver for this is currently compiled as a module. Doing RTC as a module is unfortunately broken in the general case today (see https://github.com/systemd/systemd/issues/17737 and https://forum.snapcraft.io/t/adding-ubuntu-core-fails-on-first-boot- with-rtc-is-present/30391/15 for details). Until a more general fix is available I would like to ask to just compile CONFIG_RTC_DRV_DS1307=y into the kernel that should cover a lot of popular chips and we already build CONFIG_RTC_DRV_DS1307_CENTURY=y To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1981078/+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 1981078] Missing required logs.
This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window: apport-collect 1981078 and then change the status of the bug to 'Confirmed'. If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'. This change has been made by an automated script, maintained by the Ubuntu Kernel Team. ** Changed in: linux (Ubuntu) Status: New => Incomplete -- 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/1981078 Title: [pi-kernel] Please set CONFIG_RTC_DRV_DS1307=y Status in linux package in Ubuntu: Incomplete Bug description: We recently got a bugreport from a user who uses a PI with an external RTC. The chips is a ds3231. The driver for this is currently compiled as a module. Doing RTC as a module is unfortunately broken in the general case today (see https://github.com/systemd/systemd/issues/17737 and https://forum.snapcraft.io/t/adding-ubuntu-core-fails-on-first-boot- with-rtc-is-present/30391/15 for details). Until a more general fix is available I would like to ask to just compile CONFIG_RTC_DRV_DS1307=y into the kernel that should cover a lot of popular chips and we already build CONFIG_RTC_DRV_DS1307_CENTURY=y To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1981078/+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 1980277] Re: Jammy update: v5.15.40 upstream stable release
** Changed in: linux (Ubuntu Jammy) Status: In Progress => Fix Committed -- 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/1980277 Title: Jammy update: v5.15.40 upstream stable release Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Committed Bug description: SRU Justification Impact: The upstream process for stable tree updates is quite similar in scope to the Ubuntu SRU process, e.g., each patch has to demonstrably fix a bug, and each patch is vetted by upstream by originating either directly from a mainline/stable Linux tree or a minimally backported form of that patch. The following upstream stable patches should be included in the Ubuntu kernel: v5.15.40 upstream stable release from git://git.kernel.org/ x86/lib/atomic64_386_32: Rename things x86: Prepare asm files for straight-line-speculation x86: Prepare inline-asm for straight-line-speculation objtool: Add straight-line-speculation validation x86/alternative: Relax text_poke_bp() constraint kbuild: move objtool_args back to scripts/Makefile.build UBUNTU: [Config] updateconfigs for SLS x86: Add straight-line-speculation mitigation tools arch: Update arch/x86/lib/mem{cpy,set}_64.S copies used in 'perf bench mem memcpy' kvm/emulate: Fix SETcc emulation function offsets with SLS crypto: x86/poly1305 - Fixup SLS objtool: Fix SLS validation for kcov tail-call replacement Bluetooth: Fix the creation of hdev->name udf: Avoid using stale lengthOfImpUse mm: fix missing cache flush for all tail pages of compound page mm: hugetlb: fix missing cache flush in copy_huge_page_from_user() mm: shmem: fix missing cache flush in shmem_mfill_atomic_pte() mm: userfaultfd: fix missing cache flush in mcopy_atomic_pte() and __mcopy_atomic() mm/hwpoison: fix error page recovered but reported "not recovered" mm/mlock: fix potential imbalanced rlimit ucounts adjustment mm: fix invalid page pointer returned with FOLL_PIN gups Linux 5.15.40 UBUNTU: Upstream stable to v5.15.40 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1980277/+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 1980278] Re: Jammy update: v5.15.41 upstream stable release
"SUNRPC: Ensure we flush any closed sockets before xs_xprt_free()" was already applied as part of CVE-2022-28893. ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2022-28893 ** Changed in: linux (Ubuntu Jammy) Status: In Progress => Fix Committed -- 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/1980278 Title: Jammy update: v5.15.41 upstream stable release Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Committed Bug description: SRU Justification Impact: The upstream process for stable tree updates is quite similar in scope to the Ubuntu SRU process, e.g., each patch has to demonstrably fix a bug, and each patch is vetted by upstream by originating either directly from a mainline/stable Linux tree or a minimally backported form of that patch. The following upstream stable patches should be included in the Ubuntu kernel: v5.15.41 upstream stable release from git://git.kernel.org/ batman-adv: Don't skb_split skbuffs with frag_list iwlwifi: iwl-dbg: Use del_timer_sync() before freeing hwmon: (tmp401) Add OF device ID table mac80211: Reset MBSSID parameters upon connection net: Fix features skip in for_each_netdev_feature() net: mscc: ocelot: fix last VCAP IS1/IS2 filter persisting in hardware when deleted net: mscc: ocelot: fix VCAP IS2 filters matching on both lookups net: mscc: ocelot: restrict tc-trap actions to VCAP IS2 lookup 0 net: mscc: ocelot: avoid corrupting hardware counters when moving VCAP filters fbdev: simplefb: Cleanup fb_info in .fb_destroy rather than .remove fbdev: efifb: Cleanup fb_info in .fb_destroy rather than .remove fbdev: vesafb: Cleanup fb_info in .fb_destroy rather than .remove platform/surface: aggregator: Fix initialization order when compiling as builtin module ice: Fix race during aux device (un)plugging ice: fix PTP stale Tx timestamps cleanup ipv4: drop dst in multicast routing path drm/nouveau: Fix a potential theorical leak in nouveau_get_backlight_name() netlink: do not reset transport header in netlink_recvmsg() net: chelsio: cxgb4: Avoid potential negative array offset fbdev: efifb: Fix a use-after-free due early fb_info cleanup sfc: Use swap() instead of open coding it net: sfc: fix memory leak due to ptp channel mac80211_hwsim: call ieee80211_tx_prepare_skb under RCU protection nfs: fix broken handling of the softreval mount option ionic: fix missing pci_release_regions() on error in ionic_probe() dim: initialize all struct fields hwmon: (ltq-cputemp) restrict it to SOC_XWAY procfs: prevent unprivileged processes accessing fdinfo dir selftests: vm: Makefile: rename TARGETS to VMTARGETS arm64: vdso: fix makefile dependency on vdso.so virtio: fix virtio transitional ids s390/ctcm: fix variable dereferenced before check s390/ctcm: fix potential memory leak s390/lcs: fix variable dereferenced before check net/sched: act_pedit: really ensure the skb is writable net: ethernet: mediatek: ppe: fix wrong size passed to memset() net: bcmgenet: Check for Wake-on-LAN interrupt probe deferral drm/vc4: hdmi: Fix build error for implicit function declaration net: dsa: bcm_sf2: Fix Wake-on-LAN with mac_link_down() net/smc: non blocking recvmsg() return -EAGAIN when no data and signal_pending net: sfc: ef10: fix memory leak in efx_ef10_mtd_probe() tls: Fix context leak on tls_device_down drm/vmwgfx: Fix fencing on SVGAv3 gfs2: Fix filesystem block deallocation for short writes hwmon: (f71882fg) Fix negative temperature RDMA/irdma: Fix deadlock in irdma_cleanup_cm_core() iommu: arm-smmu: disable large page mappings for Nvidia arm-smmu ASoC: max98090: Reject invalid values in custom control put() ASoC: max98090: Generate notifications on changes for custom control ASoC: ops: Validate input values in snd_soc_put_volsw_range() s390: disable -Warray-bounds ASoC: SOF: Fix NULL pointer exception in sof_pci_probe callback net: emaclite: Don't advertise 1000BASE-T and do auto negotiation net: sfp: Add tx-fault workaround for Huawei MA5671A SFP ONT secure_seq: use the 64 bits of the siphash for port offset calculation tcp: use different parts of the port_offset for index and offset tcp: resalt the secret every 10 seconds tcp: add small random increments to the source port tcp: dynamically allocate the perturb table used by source ports tcp: increase source port perturb table to 2^16 tcp: drop the hash_32() part from the index calculation interconnect: Restore sync state by ignoring ipa-virt in provider count firmware_loader: use kernel credentials when reading firmware KVM: PPC: Book3S PR: Enable MSR_DR for switch_mmu_context() usb: xhci-mtk: fix fs isoc's transfer error x86/mm: Fix marking of unused sub-pmd
[Kernel-packages] [Bug 1980399] Re: Focal update: v5.4.194 upstream stable release
** Changed in: linux (Ubuntu Focal) Status: In Progress => Fix Committed -- 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/1980399 Title: Focal update: v5.4.194 upstream stable release Status in linux package in Ubuntu: Invalid Status in linux source package in Focal: Fix Committed Bug description: SRU Justification Impact: The upstream process for stable tree updates is quite similar in scope to the Ubuntu SRU process, e.g., each patch has to demonstrably fix a bug, and each patch is vetted by upstream by originating either directly from a mainline/stable Linux tree or a minimally backported form of that patch. The following upstream stable patches should be included in the Ubuntu kernel: v5.4.194 upstream stable release from git://git.kernel.org/ MIPS: Use address-of operator on section symbols block: drbd: drbd_nl: Make conversion to 'enum drbd_ret_code' explicit drm/amd/display/dc/gpio/gpio_service: Pass around correct dce_{version, environment} types drm/i915: Cast remain to unsigned long in eb_relocate_vma nfp: bpf: silence bitwise vs. logical OR warning can: grcan: grcan_probe(): fix broken system id check for errata workaround needs can: grcan: only use the NAPI poll budget for RX arm: remove CONFIG_ARCH_HAS_HOLES_MEMORYMODEL UBUNTU: [Config] updateconfigs for ARCH_HAS_HOLES_MEMORYMODEL KVM: x86/pmu: Refactoring find_arch_event() to pmc_perf_hw_id() x86/asm: Allow to pass macros to __ASM_FORM() x86: xen: kvm: Gather the definition of emulate prefixes x86: xen: insn: Decode Xen and KVM emulate-prefix signature x86: kprobes: Prohibit probing on instruction which has emulate prefix KVM: x86/svm: Account for family 17h event renumberings in amd_pmc_perf_hw_id Bluetooth: Fix the creation of hdev->name mm: fix missing cache flush for all tail pages of compound page mm: hugetlb: fix missing cache flush in copy_huge_page_from_user() mm: userfaultfd: fix missing cache flush in mcopy_atomic_pte() and __mcopy_atomic() Linux 5.4.194 UBUNTU: Upstream stable to v5.4.194 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1980399/+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 1979566] Re: Focal update: v5.4.193 upstream stable release
"nfc: nfcmrvl: main: reorder destructive operations in nfcmrvl_nci_unregister_dev to avoid bugs" already applied for CVE-2022-1734 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2022-1734 ** Changed in: linux (Ubuntu Focal) Status: In Progress => Fix Committed -- 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/1979566 Title: Focal update: v5.4.193 upstream stable release Status in linux package in Ubuntu: Invalid Status in linux source package in Focal: Fix Committed Bug description: SRU Justification Impact: The upstream process for stable tree updates is quite similar in scope to the Ubuntu SRU process, e.g., each patch has to demonstrably fix a bug, and each patch is vetted by upstream by originating either directly from a mainline/stable Linux tree or a minimally backported form of that patch. The following upstream stable patches should be included in the Ubuntu kernel: v5.4.193 upstream stable release from git://git.kernel.org/ MIPS: Fix CP0 counter erratum detection for R4k CPUs parisc: Merge model and model name into one line in /proc/cpuinfo ALSA: fireworks: fix wrong return count shorter than expected by 4 bytes gpiolib: of: fix bounds check for 'gpio-reserved-ranges' Revert "SUNRPC: attempt AF_LOCAL connect on setup" firewire: fix potential uaf in outbound_phy_packet_callback() firewire: remove check of list iterator against head past the loop body firewire: core: extend card->lock in fw_core_handle_bus_reset ACPICA: Always create namespace nodes using acpi_ns_create_node() genirq: Synchronize interrupt thread startup ASoC: da7219: Fix change notifications for tone generator frequency ASoC: wm8958: Fix change notifications for DSP controls ASoC: meson: Fix event generation for G12A tohdmi mux s390/dasd: fix data corruption for ESE devices s390/dasd: prevent double format of tracks for ESE devices s390/dasd: Fix read for ESE with blksize < 4k s390/dasd: Fix read inconsistency for ESE DASD devices can: grcan: grcan_close(): fix deadlock can: grcan: use ofdev->dev when allocating DMA memory nfc: replace improper check device_is_registered() in netlink related functions nfc: nfcmrvl: main: reorder destructive operations in nfcmrvl_nci_unregister_dev to avoid bugs NFC: netlink: fix sleep in atomic bug when firmware download timeout hwmon: (adt7470) Fix warning on module removal ASoC: dmaengine: Restore NULL prepare_slave_config() callback RDMA/siw: Fix a condition race issue in MPA request processing net: ethernet: mediatek: add missing of_node_put() in mtk_sgmii_init() net: stmmac: dwmac-sun8i: add missing of_node_put() in sun8i_dwmac_register_mdio_mux() net: emaclite: Add error handling for of_address_to_resource() selftests: mirror_gre_bridge_1q: Avoid changing PVID while interface is operational bnxt_en: Fix possible bnxt_open() failure caused by wrong RFS flag smsc911x: allow using IRQ0 btrfs: always log symlinks in full mode net: igmp: respect RCU rules in ip_mc_source() and ip_mc_msfilter() drm/amdkfd: Use drm_priv to pass VM from KFD to amdgpu NFSv4: Don't invalidate inode attributes on delegation return kvm: x86/cpuid: Only provide CPUID leaf 0xA if host has architectural PMU x86/kvm: Preserve BSP MSR_KVM_POLL_CONTROL across suspend/resume KVM: LAPIC: Enable timer posted-interrupt only when mwait/hlt is advertised net: ipv6: ensure we call ipv6_mc_down() at most once block-map: add __GFP_ZERO flag for alloc_page in function bio_copy_kern mm: fix unexpected zeroed page mapping with zram swap ALSA: pcm: Fix races among concurrent hw_params and hw_free calls ALSA: pcm: Fix races among concurrent read/write and buffer changes ALSA: pcm: Fix races among concurrent prepare and hw_params/hw_free calls ALSA: pcm: Fix races among concurrent prealloc proc writes ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lock tcp: make sure treq->af_specific is initialized dm: fix mempool NULL pointer race when completing IO dm: interlock pending dm_io and dm_wait_for_bios_completion PCI: aardvark: Clear all MSIs at setup PCI: aardvark: Fix reading MSI interrupt number mmc: rtsx: add 74 Clocks in power on flow Linux 5.4.193 UBUNTU: upstream stable to v5.4.193 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1979566/+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 1981078] Re: [pi-kernel] Please set CONFIG_RTC_DRV_DS1307=y
** Changed in: linux (Ubuntu) Status: Incomplete => New ** 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/1981078 Title: [pi-kernel] Please set CONFIG_RTC_DRV_DS1307=y Status in linux package in Ubuntu: Confirmed Bug description: We recently got a bugreport from a user who uses a PI with an external RTC. The chips is a ds3231. The driver for this is currently compiled as a module. Doing RTC as a module is unfortunately broken in the general case today (see https://github.com/systemd/systemd/issues/17737 and https://forum.snapcraft.io/t/adding-ubuntu-core-fails-on-first-boot- with-rtc-is-present/30391/15 for details). Until a more general fix is available I would like to ask to just compile CONFIG_RTC_DRV_DS1307=y into the kernel that should cover a lot of popular chips and we already build CONFIG_RTC_DRV_DS1307_CENTURY=y To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1981078/+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 1980407] Re: Focal update: v5.4.195 upstream stable release
** Changed in: linux (Ubuntu Focal) Status: In Progress => Fix Committed -- 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/1980407 Title: Focal update: v5.4.195 upstream stable release Status in linux package in Ubuntu: Invalid Status in linux source package in Focal: Fix Committed Bug description: SRU Justification Impact: The upstream process for stable tree updates is quite similar in scope to the Ubuntu SRU process, e.g., each patch has to demonstrably fix a bug, and each patch is vetted by upstream by originating either directly from a mainline/stable Linux tree or a minimally backported form of that patch. The following upstream stable patches should be included in the Ubuntu kernel: v5.4.195 upstream stable release from git://git.kernel.org/ batman-adv: Don't skb_split skbuffs with frag_list hwmon: (tmp401) Add OF device ID table mac80211: Reset MBSSID parameters upon connection net: Fix features skip in for_each_netdev_feature() ipv4: drop dst in multicast routing path drm/nouveau: Fix a potential theorical leak in nouveau_get_backlight_name() netlink: do not reset transport header in netlink_recvmsg() mac80211_hwsim: call ieee80211_tx_prepare_skb under RCU protection dim: initialize all struct fields hwmon: (ltq-cputemp) restrict it to SOC_XWAY s390/ctcm: fix variable dereferenced before check s390/ctcm: fix potential memory leak s390/lcs: fix variable dereferenced before check net/sched: act_pedit: really ensure the skb is writable net/smc: non blocking recvmsg() return -EAGAIN when no data and signal_pending net: sfc: ef10: fix memory leak in efx_ef10_mtd_probe() gfs2: Fix filesystem block deallocation for short writes hwmon: (f71882fg) Fix negative temperature ASoC: max98090: Reject invalid values in custom control put() ASoC: max98090: Generate notifications on changes for custom control ASoC: ops: Validate input values in snd_soc_put_volsw_range() s390: disable -Warray-bounds net: emaclite: Don't advertise 1000BASE-T and do auto negotiation tcp: resalt the secret every 10 seconds tty: n_gsm: fix mux activation issues in gsm_config() usb: cdc-wdm: fix reading stuck on device close usb: typec: tcpci: Don't skip cleanup in .remove() on error USB: serial: pl2303: add device id for HP LM930 Display USB: serial: qcserial: add support for Sierra Wireless EM7590 USB: serial: option: add Fibocom L610 modem USB: serial: option: add Fibocom MA510 modem slimbus: qcom: Fix IRQ check in qcom_slim_probe serial: 8250_mtk: Fix UART_EFR register address serial: 8250_mtk: Fix register address for XON/XOFF character drm/nouveau/tegra: Stop using iommu_present() i40e: i40e_main: fix a missing check on list iterator cgroup/cpuset: Remove cpus_allowed/mems_allowed setup in cpuset_init_smp() drm/vmwgfx: Initialize drm_mode_fb_cmd2 MIPS: fix build with gcc-12 net: phy: Fix race condition on link status change arm[64]/memremap: don't abuse pfn_valid() to ensure presence of linear map ping: fix address binding wrt vrf tty/serial: digicolor: fix possible null-ptr-deref in digicolor_uart_probe() Linux 5.4.195 UBUNTU: Upstream stable to v5.4.195 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1980407/+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 1978915] Re: alsa/hda: mute led can't work on the lenovo machine with cs35l41 s-codec
** Changed in: linux (Ubuntu Jammy) Importance: Undecided => Medium ** Changed in: linux (Ubuntu Jammy) Status: Incomplete => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-oem-5.14 in Ubuntu. https://bugs.launchpad.net/bugs/1978915 Title: alsa/hda: mute led can't work on the lenovo machine with cs35l41 s-codec Status in HWE Next: In Progress Status in linux package in Ubuntu: Incomplete Status in linux-oem-5.14 package in Ubuntu: Invalid Status in linux source package in Focal: Won't Fix Status in linux-oem-5.14 source package in Focal: Fix Released Status in linux source package in Jammy: Fix Committed Status in linux-oem-5.14 source package in Jammy: Invalid Bug description: The fix is already in the upstream kernel stable-v5.17, no need to send this patch to oem-5.17 and unstable kernels. [Impact] After we apply the cs35l41 s-codec patchset to the oem-5.14 and jammy kernels, the mute led can't work anymore. [Fix] Backport a patch from mainline kernel to fix this regression [Test] boot the patched kernel, press mute hotkey, the speaker is muted and the mute led is on, press the mute hotkey again, the speaker is unmuted and the mute led is off. [Where problems could occur] After merging this patch, it is possible to affect the machines which apply the ALC287_FIXUP_CS35L41_I2C_2, but the regression possibility is very low since hda_fixup_thinkpad_acpi() could check if the quirk is suitable for the running machine. And we did test, all machines could work well. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1978915/+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 1978925] Re: Fix headset mic no sound on an HP desktop
** Changed in: linux (Ubuntu Jammy) Status: Confirmed => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-oem-5.14 in Ubuntu. https://bugs.launchpad.net/bugs/1978925 Title: Fix headset mic no sound on an HP desktop Status in HWE Next: In Progress Status in linux package in Ubuntu: Invalid Status in linux-oem-5.14 package in Ubuntu: Invalid Status in linux-oem-5.17 package in Ubuntu: Invalid Status in linux source package in Focal: Won't Fix Status in linux-oem-5.14 source package in Focal: Fix Released Status in linux-oem-5.17 source package in Focal: Invalid Status in linux source package in Impish: Won't Fix Status in linux-oem-5.14 source package in Impish: Invalid Status in linux-oem-5.17 source package in Impish: Invalid Status in linux source package in Jammy: Fix Committed Status in linux-oem-5.14 source package in Jammy: Invalid Status in linux-oem-5.17 source package in Jammy: Fix Released Bug description: [Impact] Headset MIC cannot record any sound. [Fix] Update HDA pin table to use correct verb. [Test] Affected system can record sound via headset now. [Where problems could occur] The fix uses system ID and codec variant to match platform, so only one system will be affected. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1978925/+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 1976533] Re: [UBUNTU 20.04] s390/DASD: Fix data corruption for ESE devices
Fix Committed for focal according to LP#1979566. ** Changed in: linux (Ubuntu) Status: In Progress => Fix Committed ** Changed in: ubuntu-z-systems Status: In Progress => Fix Committed -- 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/1976533 Title: [UBUNTU 20.04] s390/DASD: Fix data corruption for ESE devices Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Released Status in linux source package in Focal: Fix Committed Status in linux source package in Jammy: Fix Committed Status in linux source package in Kinetic: Fix Released Bug description: Description: s390/dasd: Fix data corruption for ESE devices Symptom: Filesystem errors and data inconsistency. Problem: Wrong tracks are formatted or the same track is formatted twice. 1. For ESE devices we get an error when accessing an unformatted track. The handling of this error will return zero data for read requests and format the track on demand before writing to it. To do this the code needs to distinguish between read and write requests. This is done with data from the blocklayer request. A pointer to the blocklayer request is stored in the CQR. If there is an error on the device an ERP request is built to do error recovery. While the ERP request is mostly a copy of the original CQR the pointer to the blocklayer request is not copied to not accidentally pass it back to the blocklayer without cleanup. This leads to the error that during ESE handling after an ERP request was built it is not possible to determine the IO direction. This leads to the formatting of a track for read requests which might in turn lead to data corruption. 2. When using alias devices a track might be accessed by multiple requests simultaneously and there is a race window that a track gets formatted twice resulting in data loss. Solution: 1. Return the callback data of the original request in case there are ERP requests build on top of it and thus determine the correct IO direction. 2. Prevent the double format by remembering the amount of formatted tracks when starting a request and comparing this number before actually formatting a track on the fly. If the number has changed there is a chance that the current track was finally formatted in between. As a result do not format the track and restart the current IO to check. Reproduction: Prepare an ESE DASD device using dasdfmt and fdasd. Install any filesystem on the prepared partitions and issue regular I/O using dd or any other tool while Alias DASD devices are set online as well. Upstream-ID: 5b53a405e4658580e1faf7c217db3f55a21ba849 71f3871657370dbbaf942a1c758f64e49a36c70f Problem-ID:198418 Preventive:yes Date: 2022-06-01 Author:hoepp...@linux.ibm.com Component: kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1976533/+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 1959973] Re: [22.04 FEAT] KVM: Attestation support for Secure Execution (crypto)
** Changed in: linux (Ubuntu Jammy) Status: In Progress => Fix Committed -- 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/1959973 Title: [22.04 FEAT] KVM: Attestation support for Secure Execution (crypto) Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Committed Bug description: SRU Justification: == [Impact] * This is a hardware enablement SRU in support of IBM z15 and LinuxONE III (FC 115) secure execution feature. * It adds a misc character device to expose some Ultravisor functions to userspace. * The device is only available if the (optional) Ultravisor Facility (158) is present in the system. * Two Ultravisor calls are supported: - Query Ultravisor Information (QUI) and - Receive Attestation Measurement (Attest[ation]) * This is in support of for example. external frameworks, specific deployment models or especially potentially regulatory requirements. [Fix] * 4689752c79fa 4689752c79fa30e91b49b39a9fba93c4d1f3e20c "drivers/s390/char: Add Ultravisor io device" * eb3de2d8f78d eb3de2d8f78d893303891d879f941c47f2f2d13d "s390/uv_uapi: depend on CONFIG_S390" * patch to set kernel config option 'CONFIG_S390_UV_UAPI=y' [Test Plan] * An IBM z15 or LinuxONE III LPAR with FC 115 enabled is required. * Installation of Ubuntu Server 22.04 LTS on top. * Install a kernel that incl. the above patches/commits (that has the kernel config option 'CONFIG_S390_UV_UAPI' enabled). * Activate the kernel (reboot) and look for the existence of the uvdevice '/dev/uv'. * Use a userspace test program that makes use of the new misc device by exploiting 'ATTEST'. * Due to hardware requirements this test needs to be conducted by IBM. [Where problems could occur] * The definitions in uv_cmds_inst and uv_feat_ind could be wrong and the codes wrong or mixed up, which would lead to a broken functionality/interface. * The uvdevice header definitions could be erroneous, defining an wrong interface. * The newly added kernel options could be implemented in a wrong way, so that it doesn't enable the 'uvdevice', but unlikely. * The implementation of the device itself in 'uvdevice.c' could be broken by wrong or broken pointer arithmetics, wrong method arguments, wrong sizeof/length calculations, which - in worst case - could entirely crash a system. * The ioctl control block implementation could be wrong in a way, that it doesn't properly handle the case where the facility is not available in the system. * Entry point, copy and check routines could be wrong, allowing non-desired calls. * This is an s390x-only functionality, that is only available on IBM z15 / LinuxONE III systems and newer, and only is the optional feature 'FC 115' in place, which is limited to 'secure-execution' workloads. [Other Info] * The above commit is marked to be merged into 5.19-rc2, and since the planned target kernel for kinetic is 5.19, the SRU is not needed for kinetic. __ KVM: Attestation support for Secure Execution (crypto) Description: Provide attestations support, e.g. for external frameworks, specific deployment models or potentially regulatory requirements. Request Type: Kernel - Enhancement from IBM Upstream Acceptance: In Progress To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1959973/+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 1981087] [NEW] thermald prematurely throttling GPU
Public bug reported: I got a new game and started playing it It would run at over 100 FPS solidly some of the time and then cyclically dip down to below 20 FPS for a few minutes I determined that it was thermald trying to keep my GPU below 70°C to determine this I sudo systemctl stop thermald The game ran solidly and consistently with the GPU at 75°C This is well below the specs set by the manufacturer and perhaps unreasonably low for a laptop But more importantly importantly I was given no indication this was happening. I had to sleuth it out myself. Perhaps it is impossible to determine good defaults for all hardware, I don't know. However without an indication that this is happening there will be a lot of people with a mysteriously broken experience. This was extremely difficult for me to find and I had several friend who are experts on linux gaming and video drivers trying to track this down. I discovered it by luck and perseverance. This absolutely needs some sort of indication and hopefully a way to remedy it from the GUI. ideally it would set thermal limits that are more in line with what the device is designed for and not a conservative default if at all possible. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: thermald 2.4.9-1 ProcVersionSignature: Ubuntu 5.15.0-40.43-generic 5.15.35 Uname: Linux 5.15.0-40-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: XFCE Date: Fri Jul 8 16:08:55 2022 InstallationDate: Installed on 2020-10-19 (626 days ago) InstallationMedia: Xubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) SourcePackage: thermald UpgradeStatus: Upgraded to jammy on 2022-06-17 (20 days ago) ** Affects: thermald (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug jammy -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to thermald in Ubuntu. https://bugs.launchpad.net/bugs/1981087 Title: thermald prematurely throttling GPU Status in thermald package in Ubuntu: New Bug description: I got a new game and started playing it It would run at over 100 FPS solidly some of the time and then cyclically dip down to below 20 FPS for a few minutes I determined that it was thermald trying to keep my GPU below 70°C to determine this I sudo systemctl stop thermald The game ran solidly and consistently with the GPU at 75°C This is well below the specs set by the manufacturer and perhaps unreasonably low for a laptop But more importantly importantly I was given no indication this was happening. I had to sleuth it out myself. Perhaps it is impossible to determine good defaults for all hardware, I don't know. However without an indication that this is happening there will be a lot of people with a mysteriously broken experience. This was extremely difficult for me to find and I had several friend who are experts on linux gaming and video drivers trying to track this down. I discovered it by luck and perseverance. This absolutely needs some sort of indication and hopefully a way to remedy it from the GUI. ideally it would set thermal limits that are more in line with what the device is designed for and not a conservative default if at all possible. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: thermald 2.4.9-1 ProcVersionSignature: Ubuntu 5.15.0-40.43-generic 5.15.35 Uname: Linux 5.15.0-40-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: XFCE Date: Fri Jul 8 16:08:55 2022 InstallationDate: Installed on 2020-10-19 (626 days ago) InstallationMedia: Xubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) SourcePackage: thermald UpgradeStatus: Upgraded to jammy on 2022-06-17 (20 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/thermald/+bug/1981087/+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 1976533] Re: [UBUNTU 20.04] s390/DASD: Fix data corruption for ESE devices
The patch is currently also in jammy-proposed: linux-generic | 5.15.0.41.43 | jammy-proposed hence marking jammy as Fix Committed, and it's upstream with 5.18, hence will be part of kinetic's target kernel. ** Also affects: linux (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Kinetic) Importance: High Assignee: Skipper Bug Screeners (skipper-screen-team) Status: Fix Committed ** Changed in: linux (Ubuntu Kinetic) Status: Fix Committed => Fix Released ** Changed in: linux (Ubuntu Jammy) Status: New => Fix Committed ** Changed in: linux (Ubuntu Focal) Status: New => Fix Committed ** Changed in: linux (Ubuntu Kinetic) Assignee: Skipper Bug Screeners (skipper-screen-team) => (unassigned) ** Changed in: linux (Ubuntu Jammy) Importance: Undecided => High ** Changed in: linux (Ubuntu Focal) Importance: Undecided => High -- 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/1976533 Title: [UBUNTU 20.04] s390/DASD: Fix data corruption for ESE devices Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Released Status in linux source package in Focal: Fix Committed Status in linux source package in Jammy: Fix Committed Status in linux source package in Kinetic: Fix Released Bug description: Description: s390/dasd: Fix data corruption for ESE devices Symptom: Filesystem errors and data inconsistency. Problem: Wrong tracks are formatted or the same track is formatted twice. 1. For ESE devices we get an error when accessing an unformatted track. The handling of this error will return zero data for read requests and format the track on demand before writing to it. To do this the code needs to distinguish between read and write requests. This is done with data from the blocklayer request. A pointer to the blocklayer request is stored in the CQR. If there is an error on the device an ERP request is built to do error recovery. While the ERP request is mostly a copy of the original CQR the pointer to the blocklayer request is not copied to not accidentally pass it back to the blocklayer without cleanup. This leads to the error that during ESE handling after an ERP request was built it is not possible to determine the IO direction. This leads to the formatting of a track for read requests which might in turn lead to data corruption. 2. When using alias devices a track might be accessed by multiple requests simultaneously and there is a race window that a track gets formatted twice resulting in data loss. Solution: 1. Return the callback data of the original request in case there are ERP requests build on top of it and thus determine the correct IO direction. 2. Prevent the double format by remembering the amount of formatted tracks when starting a request and comparing this number before actually formatting a track on the fly. If the number has changed there is a chance that the current track was finally formatted in between. As a result do not format the track and restart the current IO to check. Reproduction: Prepare an ESE DASD device using dasdfmt and fdasd. Install any filesystem on the prepared partitions and issue regular I/O using dd or any other tool while Alias DASD devices are set online as well. Upstream-ID: 5b53a405e4658580e1faf7c217db3f55a21ba849 71f3871657370dbbaf942a1c758f64e49a36c70f Problem-ID:198418 Preventive:yes Date: 2022-06-01 Author:hoepp...@linux.ibm.com Component: kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1976533/+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 1959973] Re: [22.04 FEAT] KVM: Attestation support for Secure Execution (crypto)
** Changed in: ubuntu-z-systems Status: In Progress => Fix Committed -- 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/1959973 Title: [22.04 FEAT] KVM: Attestation support for Secure Execution (crypto) Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Committed Bug description: SRU Justification: == [Impact] * This is a hardware enablement SRU in support of IBM z15 and LinuxONE III (FC 115) secure execution feature. * It adds a misc character device to expose some Ultravisor functions to userspace. * The device is only available if the (optional) Ultravisor Facility (158) is present in the system. * Two Ultravisor calls are supported: - Query Ultravisor Information (QUI) and - Receive Attestation Measurement (Attest[ation]) * This is in support of for example. external frameworks, specific deployment models or especially potentially regulatory requirements. [Fix] * 4689752c79fa 4689752c79fa30e91b49b39a9fba93c4d1f3e20c "drivers/s390/char: Add Ultravisor io device" * eb3de2d8f78d eb3de2d8f78d893303891d879f941c47f2f2d13d "s390/uv_uapi: depend on CONFIG_S390" * patch to set kernel config option 'CONFIG_S390_UV_UAPI=y' [Test Plan] * An IBM z15 or LinuxONE III LPAR with FC 115 enabled is required. * Installation of Ubuntu Server 22.04 LTS on top. * Install a kernel that incl. the above patches/commits (that has the kernel config option 'CONFIG_S390_UV_UAPI' enabled). * Activate the kernel (reboot) and look for the existence of the uvdevice '/dev/uv'. * Use a userspace test program that makes use of the new misc device by exploiting 'ATTEST'. * Due to hardware requirements this test needs to be conducted by IBM. [Where problems could occur] * The definitions in uv_cmds_inst and uv_feat_ind could be wrong and the codes wrong or mixed up, which would lead to a broken functionality/interface. * The uvdevice header definitions could be erroneous, defining an wrong interface. * The newly added kernel options could be implemented in a wrong way, so that it doesn't enable the 'uvdevice', but unlikely. * The implementation of the device itself in 'uvdevice.c' could be broken by wrong or broken pointer arithmetics, wrong method arguments, wrong sizeof/length calculations, which - in worst case - could entirely crash a system. * The ioctl control block implementation could be wrong in a way, that it doesn't properly handle the case where the facility is not available in the system. * Entry point, copy and check routines could be wrong, allowing non-desired calls. * This is an s390x-only functionality, that is only available on IBM z15 / LinuxONE III systems and newer, and only is the optional feature 'FC 115' in place, which is limited to 'secure-execution' workloads. [Other Info] * The above commit is marked to be merged into 5.19-rc2, and since the planned target kernel for kinetic is 5.19, the SRU is not needed for kinetic. __ KVM: Attestation support for Secure Execution (crypto) Description: Provide attestations support, e.g. for external frameworks, specific deployment models or potentially regulatory requirements. Request Type: Kernel - Enhancement from IBM Upstream Acceptance: In Progress To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1959973/+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 1981087] Re: thermald prematurely throttling GPU
** Description changed: I got a new game and started playing it It would run at over 100 FPS solidly some of the time and then cyclically dip down to below 20 FPS for a few minutes I determined that it was thermald trying to keep my GPU below 70°C to determine this I sudo systemctl stop thermald The game ran solidly and consistently with the GPU at 75°C This is well below the specs set by the manufacturer and perhaps unreasonably low for a laptop - But more importantly importantly I was given no indication this was - happening. I had to sleuth it out myself. + But more importantly I was given no indication this was happening. I had + to sleuth it out myself. Perhaps it is impossible to determine good defaults for all hardware, I don't know. However without an indication that this is happening there will be a lot of people with a mysteriously broken experience. This was extremely difficult for me to find and I had several friend who are experts on linux gaming and video drivers trying to track this down. I discovered it by luck and perseverance. This absolutely needs some sort of indication and hopefully a way to remedy it from the GUI. ideally it would set thermal limits that are more in line with what the device is designed for and not a conservative default if at all possible. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: thermald 2.4.9-1 ProcVersionSignature: Ubuntu 5.15.0-40.43-generic 5.15.35 Uname: Linux 5.15.0-40-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: XFCE Date: Fri Jul 8 16:08:55 2022 InstallationDate: Installed on 2020-10-19 (626 days ago) InstallationMedia: Xubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) SourcePackage: thermald UpgradeStatus: Upgraded to jammy on 2022-06-17 (20 days ago) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to thermald in Ubuntu. https://bugs.launchpad.net/bugs/1981087 Title: thermald prematurely throttling GPU Status in thermald package in Ubuntu: New Bug description: I got a new game and started playing it It would run at over 100 FPS solidly some of the time and then cyclically dip down to below 20 FPS for a few minutes I determined that it was thermald trying to keep my GPU below 70°C to determine this I sudo systemctl stop thermald The game ran solidly and consistently with the GPU at 75°C This is well below the specs set by the manufacturer and perhaps unreasonably low for a laptop But more importantly I was given no indication this was happening. I had to sleuth it out myself. Perhaps it is impossible to determine good defaults for all hardware, I don't know. However without an indication that this is happening there will be a lot of people with a mysteriously broken experience. This was extremely difficult for me to find and I had several friend who are experts on linux gaming and video drivers trying to track this down. I discovered it by luck and perseverance. This absolutely needs some sort of indication and hopefully a way to remedy it from the GUI. ideally it would set thermal limits that are more in line with what the device is designed for and not a conservative default if at all possible. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: thermald 2.4.9-1 ProcVersionSignature: Ubuntu 5.15.0-40.43-generic 5.15.35 Uname: Linux 5.15.0-40-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: XFCE Date: Fri Jul 8 16:08:55 2022 InstallationDate: Installed on 2020-10-19 (626 days ago) InstallationMedia: Xubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) SourcePackage: thermald UpgradeStatus: Upgraded to jammy on 2022-06-17 (20 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/thermald/+bug/1981087/+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 1896350] Re: nbd: requests can become stuck when disconnecting from server with qemu-nbd
** Changed in: linux (Ubuntu Impish) Status: In Progress => Won't Fix ** Changed in: linux (Ubuntu Jammy) Status: In Progress => Fix Committed -- 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/1896350 Title: nbd: requests can become stuck when disconnecting from server with qemu-nbd Status in linux package in Ubuntu: Fix Committed Status in linux source package in Bionic: Won't Fix Status in linux source package in Focal: In Progress Status in linux source package in Impish: Won't Fix Status in linux source package in Jammy: Fix Committed Status in linux source package in Kinetic: Fix Committed Bug description: BugLink: https://bugs.launchpad.net/bugs/1896350 [Impact] After 2516ab1("nbd: only clear the queue on device teardown"), present in 4.12-rc1 onward, the ioctl NBD_CLEAR_SOCK can no longer clear requests currently being processed. This change was made to fix a race between using the NBD_CLEAR_SOCK ioctl to clear requests, and teardown of the device clearing requests. This worked for the most part, as several years ago systemd was not set up to watch nbd devices for changes in their state. But after: commit f82abfcda58168d9f667e2094d438763531d3fa6 From: Tony Asleson Date: Fri, 8 Feb 2019 15:47:10 -0600 Subject: rules: watch metadata changes on nbd devices Link: https://github.com/systemd/systemd/commit/f82abfcda58168d9f667e2094d438763531d3fa6 in systemd v242-rc1, nbd* devices were added to a udev rule to watch those devices for changes with the inotify subsystem. From man udev: > watch > Watch the device node with inotify; when the node is closed after being > opened for writing, a change uevent is synthesized. > > nowatch > Disable the watching of a device node with inotify. This changed the behaviour of device teardown, since systemd now keeps tabs on the device with inotify, outstanding requests cannot be cleared as nbd_xmit_timeout() will always return 'BLK_EH_RESET_TIMER', and requests get stuck, never to complete, because a disconnect has occurred, and never to timeout, as their timers keep being reset. Symptoms of this issue is that the nbd subsystem gets stuck with messages like: block nbd15: NBD_DISCONNECT block nbd15: Send disconnect failed -32 ... block nbd15: Possible stuck request 7fcf62ba: control (read@523915264,24576B). Runtime 30 seconds ... block nbd15: Possible stuck request 7fcf62ba: control (read@523915264,24576B). Runtime 150 seconds ... INFO: task qemu-nbd:1267 blocked for more than 120 seconds. Not tainted 5.15.0-23-generic #23-Ubuntu "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:qemu-nbdstate:D stack:0 pid: 1267 ppid: 1 flags:0x0002 Call Trace: __schedule+0x23d/0x590 ? call_rcu+0xe/0x10 schedule+0x4e/0xb0 blk_mq_freeze_queue_wait+0x69/0xa0 ? wait_woken+0x70/0x70 blk_mq_freeze_queue+0x1b/0x30 nbd_add_socket+0x76/0x1f0 [nbd] __nbd_ioctl+0x18b/0x340 [nbd] ? security_capable+0x3d/0x60 nbd_ioctl+0x81/0xb0 [nbd] blkdev_ioctl+0x12e/0x270 ? __fget_files+0x86/0xc0 block_ioctl+0x46/0x50 __x64_sys_ioctl+0x91/0xc0 do_syscall_64+0x5c/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae Additionally, in syslog you will also see systemd-udevd get stuck: systemd-udevd[419]: nbd15: Worker [2004] processing SEQNUM=5661 is taking a long time $ ps aux ... 4191194 root D 0.1 systemd-udevd - We can workaround the issue by adding a higher priority udev rule to not watch nbd* devices. $ cat << EOF >> /etc/udev/rules.d/97-nbd-device.rules # Disable inotify watching of change events for NBD devices ACTION=="add|change", KERNEL=="nbd*", OPTIONS:="nowatch" EOF $ sudo udevadm control --reload-rules $ sudo udevadm trigger [Fix] The fix relies on infrastructure provided by the flag NBD_CMD_INFLIGHT, which was introduced in 5.16, and added to in 5.19. We need to backport all commits related to NBD_CMD_INFLIGHT to our kernels for the fix to be effective. For Focal, Impish and Jammy: commit 4e6eef5dc25b528e08ac5b5f64f6ca9d9987241d Author: Yu Kuai Date: Thu Sep 16 17:33:44 2021 +0800 Subject: nbd: don't handle response without a corresponding request message Link: https://github.com/torvalds/linux/commit/4e6eef5dc25b528e08ac5b5f64f6ca9d9987241d commit 07175cb1baf4c51051b1fbd391097e349f9a02a9 Author: Yu Kuai Date: Thu Sep 16 17:33:45 2021 +0800 Subject: nbd: make sure request completion won't concurrent Link: https://github.com/torvalds/linux/commit/07175cb1baf4c51051b1fbd391097e349f9a02a9 commit 2895f1831e911ca87d4efdf43e35eb72a0c7e66e Author: Yu Kuai Date: Sat May 21 15:37:46 2022 +0800 Subject: nbd: don't clear 'NBD_CMD_INFLIGHT' flag if reque
[Kernel-packages] [Bug 1979296] Re: [UBUNTU 20.04] Include patches to avoid self-detected stall with Secure Execution
** Changed in: linux (Ubuntu Jammy) Status: In Progress => Fix Committed ** Changed in: linux (Ubuntu Focal) Status: In Progress => Fix Committed -- 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/1979296 Title: [UBUNTU 20.04] Include patches to avoid self-detected stall with Secure Execution Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: Invalid Status in linux source package in Focal: Fix Committed Status in linux source package in Jammy: Fix Committed Bug description: SRU Justification: == [Impact] * On IBM Z secure execution environments under heavy load (means with over-committed resources - KVM guests) rcu_sched self-detected stalls can occur, which lead to LPAR crashes. [Fix] * 57c5df13eca4 57c5df13eca4017ed28f9375dc1d246ec0f54217 "KVM: s390: pv: add macros for UVC CC values" * 1e2aa46de526 1e2aa46de526a5adafe580bca4c25856bb06f09e "KVM: s390: pv: avoid stalls for kvm_s390_pv_init_vm" * f0a1a0615a6f f0a1a0615a6ff6d38af2c65a522698fb4bb85df6 "KVM: s390: pv: avoid stalls when making pages secure" [Test Plan] * An IBM z15 or LinuxONE III LPAR with FC 115 (secure execution) enabled is required. * Installation of Ubuntu Server 20.04 LTS (18.04 with hwe-5.4) or 22.04 LTS on top. * Install a kernel that incl. the above two patches/commits * Bring the system under high load with KVM guests. * Monitor dmesg for 'rcu_sched self-detected stalls' and/or look for crashes. * Due to hardware requirements this test needs to be conducted by IBM. [Where problems could occur] * The definition from 57c5df13eca4 are missing in both jammy and focal, but shouldn't harm. * The change in 1e2aa46de526 only uses uv_call_sched instead of just uv_call, which should lead to a snappier system under high load, but may consume overall some more cycles. * With f0a1a0615a6f the uv_call_sched cannot simply replace uv_call, due to locks being held. * Instead __uv_call is replacing uv_call, which does not loop. * But due to these changes of the (uv) calls, - in case erroneous - they may lead to wrong states, and even broken ultravisor calls and with that broken secure execution (SE). * As a side effect the uv might no longer loop over all pages, and in worst case leaving some unprotected. * All this is s390x-only functionality, that is only available on IBM z15 / LinuxONE III systems and newer, and only is the optional feature 'FC 115' in place, which is limited to 'secure-execution' workloads. [Other Info] * Patches are upstream accepted with kernel 5.16. * Commit 1e2aa46de526 is already included in jammy but 57c5df13eca4 and f0a1a0615a6f are missing. * Focal requires all 3 commits 57c5df13eca4, 1e2aa46de526 and f0a1a0615a6f. * Since impish is very close to it's EOL, it's not covered by this SRU. __ ---Problem Description--- rcu_sched self-detected stall with Secure Execution When the system is busy and additional Secure Execution guests are started, the LPAR crashes. Christian Borntraeger looked at the stack trace and identified two commits which should fix the issue: 1e2aa46de526a5adafe580bca4c25856bb06f09e and f0a1a0615a6ff6d38af2c65a522698fb4bb85df6 Please include these two fixes into 20.04, and 18.04 HWE. Here the stack trace: [592792.725078] rcu: INFO: rcu_sched self-detected stall on CPU [592792.725089] rcu: 4-: (2099 ticks this GP) idle=7d2/1/0x4002 softirq=3920041/3920042 fqs=984 [592792.725133] (t=2100 jiffies g=26268505 q=410280) [592792.725135] Task dump for CPU 4: [592792.725137] qemu-system-s39 R running task0 2557923 1644255 0x0604 [592792.725139] Call Trace: [592792.725146] ([<00566e2dcf52>] show_stack+0x7a/0xc0) [592792.725150] [<00566dab696c>] sched_show_task.part.0+0xdc/0x100 [592792.725151] [<00566e2df248>] rcu_dump_cpu_stacks+0xc0/0x100 [592792.725154] [<00566db0510c>] rcu_sched_clock_irq+0x75c/0x980 [592792.725156] [<00566db1326c>] update_process_times+0x3c/0x80 [592792.725160] [<00566db24fea>] tick_sched_handle.isra.0+0x4a/0x70 [592792.725161] [<00566db2528e>] tick_sched_timer+0x5e/0xc0 [592792.725163] [<00566db14294>] __hrtimer_run_queues+0x114/0x2f0 [592792.725165] [<00566db14fdc>] hrtimer_interrupt+0x12c/0x2a0 [592792.725167] [<00566da14b6a>] do_IRQ+0xaa/0xb0 [592792.725170] [<00566e2eed08>] ext_int_handler+0x130/0x134 [592792.725174] [<00566da2bad8>] gmap_make_secure+0x1c8/0x340 [592792.725175] ([<00566da2b9fe>] gmap_make_secure+0xee/0x340) [592792.725180] [<00566da6e796>] kvm_s390_pv_unpack+0xc6/0x2b0 [592792.725183] [<00566da535c0>] kvm_s390_handle_pv+0x390/0x
[Kernel-packages] [Bug 1980307] Re: Suppress harmless warning from hp-wmi
** Changed in: linux (Ubuntu Jammy) Status: Confirmed => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-oem-5.14 in Ubuntu. https://bugs.launchpad.net/bugs/1980307 Title: Suppress harmless warning from hp-wmi Status in HWE Next: New Status in linux package in Ubuntu: Invalid Status in linux-oem-5.14 package in Ubuntu: Invalid Status in linux-oem-5.17 package in Ubuntu: Invalid Status in linux source package in Focal: Won't Fix Status in linux-oem-5.14 source package in Focal: Fix Committed Status in linux-oem-5.17 source package in Focal: Invalid Status in linux source package in Jammy: Fix Committed Status in linux-oem-5.14 source package in Jammy: Invalid Status in linux-oem-5.17 source package in Jammy: Fix Committed Bug description: [Impact] Harmless warning is spewed from hp-wmi driver. [Fix] Ignore the unhandled event. [Test] No more such warning in dmesg. [Where problems could occur] The action for the event is not implemented, so ignoring it won't change any existing behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1980307/+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 1979296] Re: [UBUNTU 20.04] Include patches to avoid self-detected stall with Secure Execution
** Changed in: ubuntu-z-systems Status: In Progress => Fix Committed -- 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/1979296 Title: [UBUNTU 20.04] Include patches to avoid self-detected stall with Secure Execution Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Invalid Status in linux source package in Focal: Fix Committed Status in linux source package in Jammy: Fix Committed Bug description: SRU Justification: == [Impact] * On IBM Z secure execution environments under heavy load (means with over-committed resources - KVM guests) rcu_sched self-detected stalls can occur, which lead to LPAR crashes. [Fix] * 57c5df13eca4 57c5df13eca4017ed28f9375dc1d246ec0f54217 "KVM: s390: pv: add macros for UVC CC values" * 1e2aa46de526 1e2aa46de526a5adafe580bca4c25856bb06f09e "KVM: s390: pv: avoid stalls for kvm_s390_pv_init_vm" * f0a1a0615a6f f0a1a0615a6ff6d38af2c65a522698fb4bb85df6 "KVM: s390: pv: avoid stalls when making pages secure" [Test Plan] * An IBM z15 or LinuxONE III LPAR with FC 115 (secure execution) enabled is required. * Installation of Ubuntu Server 20.04 LTS (18.04 with hwe-5.4) or 22.04 LTS on top. * Install a kernel that incl. the above two patches/commits * Bring the system under high load with KVM guests. * Monitor dmesg for 'rcu_sched self-detected stalls' and/or look for crashes. * Due to hardware requirements this test needs to be conducted by IBM. [Where problems could occur] * The definition from 57c5df13eca4 are missing in both jammy and focal, but shouldn't harm. * The change in 1e2aa46de526 only uses uv_call_sched instead of just uv_call, which should lead to a snappier system under high load, but may consume overall some more cycles. * With f0a1a0615a6f the uv_call_sched cannot simply replace uv_call, due to locks being held. * Instead __uv_call is replacing uv_call, which does not loop. * But due to these changes of the (uv) calls, - in case erroneous - they may lead to wrong states, and even broken ultravisor calls and with that broken secure execution (SE). * As a side effect the uv might no longer loop over all pages, and in worst case leaving some unprotected. * All this is s390x-only functionality, that is only available on IBM z15 / LinuxONE III systems and newer, and only is the optional feature 'FC 115' in place, which is limited to 'secure-execution' workloads. [Other Info] * Patches are upstream accepted with kernel 5.16. * Commit 1e2aa46de526 is already included in jammy but 57c5df13eca4 and f0a1a0615a6f are missing. * Focal requires all 3 commits 57c5df13eca4, 1e2aa46de526 and f0a1a0615a6f. * Since impish is very close to it's EOL, it's not covered by this SRU. __ ---Problem Description--- rcu_sched self-detected stall with Secure Execution When the system is busy and additional Secure Execution guests are started, the LPAR crashes. Christian Borntraeger looked at the stack trace and identified two commits which should fix the issue: 1e2aa46de526a5adafe580bca4c25856bb06f09e and f0a1a0615a6ff6d38af2c65a522698fb4bb85df6 Please include these two fixes into 20.04, and 18.04 HWE. Here the stack trace: [592792.725078] rcu: INFO: rcu_sched self-detected stall on CPU [592792.725089] rcu: 4-: (2099 ticks this GP) idle=7d2/1/0x4002 softirq=3920041/3920042 fqs=984 [592792.725133] (t=2100 jiffies g=26268505 q=410280) [592792.725135] Task dump for CPU 4: [592792.725137] qemu-system-s39 R running task0 2557923 1644255 0x0604 [592792.725139] Call Trace: [592792.725146] ([<00566e2dcf52>] show_stack+0x7a/0xc0) [592792.725150] [<00566dab696c>] sched_show_task.part.0+0xdc/0x100 [592792.725151] [<00566e2df248>] rcu_dump_cpu_stacks+0xc0/0x100 [592792.725154] [<00566db0510c>] rcu_sched_clock_irq+0x75c/0x980 [592792.725156] [<00566db1326c>] update_process_times+0x3c/0x80 [592792.725160] [<00566db24fea>] tick_sched_handle.isra.0+0x4a/0x70 [592792.725161] [<00566db2528e>] tick_sched_timer+0x5e/0xc0 [592792.725163] [<00566db14294>] __hrtimer_run_queues+0x114/0x2f0 [592792.725165] [<00566db14fdc>] hrtimer_interrupt+0x12c/0x2a0 [592792.725167] [<00566da14b6a>] do_IRQ+0xaa/0xb0 [592792.725170] [<00566e2eed08>] ext_int_handler+0x130/0x134 [592792.725174] [<00566da2bad8>] gmap_make_secure+0x1c8/0x340 [592792.725175] ([<00566da2b9fe>] gmap_make_secure+0xee/0x340) [592792.725180] [<00566da6e796>] kvm_s390_pv_unpack+0xc6/0x2b0 [592792.725183] [<00566da535c0>] kvm_s390_handle_pv+0x390/0x580 [592792.725184] [<00566da55b30>] kvm_arch_vm_ioctl+0x250/0x9e0 [592792.
[Kernel-packages] [Bug 1981089] [NEW] Please have linux-tools-common Provide: bpftool
Public bug reported: In Debian, 'bpftool' is provided as a separate binary package. There are other packages in the archive (bpfcc, lava-dispatcher-host) which reference this package. Rather than patching each package in Ubuntu to know the different Ubuntu name for the package (linux-tools-common), we should make linux-tools-common Provides: bpftool. ** Affects: bpfcc (Ubuntu) Importance: Undecided Status: Triaged ** Affects: lava (Ubuntu) Importance: Undecided Status: Triaged ** Affects: linux (Ubuntu) Importance: Medium Status: Triaged ** Tags: update-excuse ** Tags added: update-excuse ** Also affects: bpfcc (Ubuntu) Importance: Undecided Status: New ** Also affects: lava (Ubuntu) Importance: Undecided Status: New ** Changed in: linux (Ubuntu) Status: New => Triaged ** Changed in: lava (Ubuntu) Status: New => Triaged ** Changed in: bpfcc (Ubuntu) Status: New => Triaged ** Changed in: linux (Ubuntu) Importance: Undecided => Medium -- 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/1981089 Title: Please have linux-tools-common Provide: bpftool Status in bpfcc package in Ubuntu: Triaged Status in lava package in Ubuntu: Triaged Status in linux package in Ubuntu: Triaged Bug description: In Debian, 'bpftool' is provided as a separate binary package. There are other packages in the archive (bpfcc, lava-dispatcher-host) which reference this package. Rather than patching each package in Ubuntu to know the different Ubuntu name for the package (linux-tools- common), we should make linux-tools-common Provides: bpftool. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bpfcc/+bug/1981089/+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 1969771] Re: Fix beacon loss for rtl8821ce on certain platforms
** Changed in: linux (Ubuntu Jammy) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-oem-5.14 in Ubuntu. https://bugs.launchpad.net/bugs/1969771 Title: Fix beacon loss for rtl8821ce on certain platforms Status in HWE Next: In Progress Status in linux-oem-5.14 package in Ubuntu: Invalid Status in linux-oem-5.17 package in Ubuntu: Invalid Status in linux source package in Focal: Invalid Status in linux-oem-5.14 source package in Focal: Fix Released Status in linux-oem-5.17 source package in Focal: Invalid Status in linux source package in Jammy: Fix Committed Status in linux-oem-5.14 source package in Jammy: Invalid Status in linux-oem-5.17 source package in Jammy: Fix Released Bug description: [SRU Justification] [Impact] On the intel ADL-U platform, the rtl8821ce suffers the beacon loss frequently because the driver doesn't received any beacon from AP. It causes the wpa-supplicant to reconnect again and again. Given it's critical to user experience and the urgent schedule, we need to SRU before getting approval. [Fix] Realtek release a fix to disable the PCI completion timeout on rtl8821ce so the PCI bus won't get stuck and can handed the received packets to the driver correctly. [Test Case] 1. Connect the WiFi to internet by selecting a internet connected AP 2. ping 8.8.8.8 to check the internet connectivity for at least 5 minutes. 3. Make sure no 'CTRL-EVENT-BEACON-LOSS' event reported from wpa_supplicant [Where problems could occur] Risk should be Low. It's only applied for RTL8821CE to disable the completion timeout capability. == Original Bug Description == [Summary] Wireless keeps connection and loses connection repeatedly. Below test cases are failed: - wireless/wireless_connection_wpa_n_nm_wlp3s0 - after-suspend-wireless/wireless_connection_wpa_bg_nm_wlp3s0 - after-suspend-wireless/wireless_connection_wpa_ac_nm_wlp3s0 - after-suspend-wireless/wireless_connection_open_n_nm_wlp3s0 - after-suspend-wireless/wireless_connection_open_bg_nm_wlp3s0 - after-suspend-wireless/wireless_connection_open_ac_nm_wlp3s0 Issue is also observed on WVA4-DVT2-C1 [Steps to reproduce] 1. Boot into OS 2. Connect network by wireless 3. Run 'sudo apt update' [Expected result] Wireless connection won't break [Actual result] Wireless loses the connection and then connect network, after a while, issue happens again. [Failure rate] 10/10 [Additional information] CID: 202202-29949, 202202-29947 SKU: WMVA5-DVT2-C1, WVA4-DVT2-C1 Image: canonical-oem-somerville-focal-amd64-20200502-85+fossa-olly-adl+X175 system-manufacturer: Dell Inc. system-product-name: Vostro 3520 bios-version: 0.5.4 CPU: 12th Gen Intel(R) Core(TM) i5-1235U (12x) GPU: :00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:4628] (rev 0c) :01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:1f9f] (rev a1) kernel-version: 5.14.0-1024-oem [Stage] Issue reported and logs collected at a later stage To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1969771/+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 1968861] Re: Support Cirrus audio codec configurations for Odin platform
** Changed in: linux (Ubuntu Jammy) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-oem-5.14 in Ubuntu. https://bugs.launchpad.net/bugs/1968861 Title: Support Cirrus audio codec configurations for Odin platform Status in HWE Next: In Progress Status in linux package in Ubuntu: Invalid Status in linux-oem-5.14 package in Ubuntu: Invalid Status in linux-oem-5.17 package in Ubuntu: Invalid Status in linux source package in Focal: Invalid Status in linux-oem-5.14 source package in Focal: Fix Released Status in linux-oem-5.17 source package in Focal: Invalid Status in linux source package in Jammy: Fix Committed Status in linux-oem-5.14 source package in Jammy: Invalid Status in linux-oem-5.17 source package in Jammy: Fix Released Bug description: [Impact] CS8409 needs new configuration for Odin platform [Fix] Cirrus provides us 2 patches to add the support which are not in upstream yet ALSA: hda/cs8409: Add Speaker Playback Switch for Cyborg ALSA: hda/cs8409: Support new Odin Variants Below series of patch is required to be applied before these 2. https://lists.ubuntu.com/archives/kernel-team/2022-April/129223.html [Test] Verified on the target machine [Where problems could occur] The first commit only affects the new added Odin platform, and the second one do some modification for other platforms which is hard to know what may lead to. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1968861/+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 1970799] Re: wifi connection on hotspot with wpa enterprise on 22.04
oh great, let's close the bug then, thanks! ** Changed in: linux (Ubuntu) Status: Confirmed => Invalid ** Changed in: network-manager (Ubuntu) Status: New => Invalid ** Changed in: wpa (Ubuntu) Status: Incomplete => Fix Released -- 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/1970799 Title: wifi connection on hotspot with wpa enterprise on 22.04 Status in Ubuntu MATE: New Status in linux package in Ubuntu: Invalid Status in network-manager package in Ubuntu: Invalid Status in wpa package in Ubuntu: Fix Released Bug description: With 20.04 I used a wifi connection with a hotspot Telenet with following parametres: security : WPA2 entreprise authentification : tunneled TLS no AC certificat drequired inner authentication : MSCHAPV2(non EAP) user name: my id password : my pswd with 22.04 it doesn’t work anymore nor with the internal broadcom wifi nor with dongles (nor my Dlink 140 nor TP-link WN7200) This problem is only present with hotspot requesting an identification (user+pswd) awith hotspots without identification everything is OK in appendice some infos --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu82 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: michelvlt 1725 F pulseaudio /dev/snd/pcmC0D0p: michelvlt 1725 F...m pulseaudio CasperMD5CheckResult: pass CurrentDesktop: MATE DistroRelease: Ubuntu 22.04 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) # Include files from /etc/network/interfaces.d: source /etc/network/interfaces.d/* InstallationDate: Installed on 2022-04-21 (7 days ago) InstallationMedia: Ubuntu-MATE 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) IpRoute: default via 192.168.86.254 dev wlp3s0 proto dhcp metric 600 10.101.9.0/24 dev pan1 proto kernel scope link src 10.101.9.1 linkdown 169.254.0.0/16 dev pan1 scope link metric 1000 linkdown 192.168.86.0/24 dev wlp3s0 proto kernel scope link src 192.168.86.157 metric 600 MachineType: Apple Inc. MacBookPro8,1 NonfreeKernelModules: wl Package: wpa PackageArchitecture: amd64 ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-25-generic root=UUID=90724096-caa9-4e64-820f-c775b9de339c ro quiet splash vt.handoff=7 ProcVersionSignature: Ubuntu 5.15.0-25.25-generic 5.15.30 RelatedPackageVersions: linux-restricted-modules-5.15.0-25-generic N/A linux-backports-modules-5.15.0-25-generic N/A linux-firmware 20220329.git681281e4-0ubuntu1 Tags: jammy Uname: Linux 5.15.0-25-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: 06/13/2019 dmi.bios.release: 0.1 dmi.bios.vendor: Apple Inc. dmi.bios.version: 87.0.0.0.0 dmi.board.asset.tag: Base Board Asset Tag# dmi.board.name: Mac-94245B3640C91C81 dmi.board.vendor: Apple Inc. dmi.board.version: MacBookPro8,1 dmi.chassis.type: 10 dmi.chassis.vendor: Apple Inc. dmi.chassis.version: Mac-94245B3640C91C81 dmi.modalias: dmi:bvnAppleInc.:bvr87.0.0.0.0:bd06/13/2019:br0.1:svnAppleInc.:pnMacBookPro8,1:pvr1.0:rvnAppleInc.:rnMac-94245B3640C91C81:rvrMacBookPro8,1:cvnAppleInc.:ct10:cvrMac-94245B3640C91C81:skuSystemSKU#: dmi.product.family: MacBook Pro dmi.product.name: MacBookPro8,1 dmi.product.sku: System SKU# dmi.product.version: 1.0 dmi.sys.vendor: Apple Inc. nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.36.4 connected started full enabled enabled enabled enabled enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-mate/+bug/1970799/+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 1949245] Re: AMD ACP 6.x DMIC Supports
** Changed in: linux (Ubuntu Jammy) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-oem-5.14 in Ubuntu. https://bugs.launchpad.net/bugs/1949245 Title: AMD ACP 6.x DMIC Supports Status in HWE Next: In Progress Status in linux package in Ubuntu: Incomplete Status in linux-oem-5.14 package in Ubuntu: Invalid Status in linux source package in Focal: Invalid Status in linux-oem-5.14 source package in Focal: Fix Released Status in linux source package in Jammy: Fix Committed Status in linux-oem-5.14 source package in Jammy: Invalid Bug description: [Impact] AMD's Yellow carp platforms will have an updated ACP IP block (ACP 6.x) which will not work with existing ACP drivers. [Fix] Backport the new driver that is now in linux-next (to be in 5.16) [Test] This is requested by AMD. [Where problems could occur] Low risk. This is a stand-alone driver that does not affect others devices and platforms. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1949245/+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 1980700] Re: alsa: asoc: amd: the internal mic can't be dedected on yellow carp machines
** Changed in: linux (Ubuntu Jammy) Importance: Undecided => Medium ** Changed in: linux (Ubuntu Jammy) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-oem-5.14 in Ubuntu. https://bugs.launchpad.net/bugs/1980700 Title: alsa: asoc: amd: the internal mic can't be dedected on yellow carp machines Status in HWE Next: In Progress Status in linux package in Ubuntu: Invalid Status in linux-oem-5.14 package in Ubuntu: Invalid Status in linux-oem-5.17 package in Ubuntu: Invalid Status in linux source package in Focal: Won't Fix Status in linux-oem-5.14 source package in Focal: Fix Committed Status in linux-oem-5.17 source package in Focal: Invalid Status in linux source package in Jammy: Fix Committed Status in linux-oem-5.14 source package in Jammy: Invalid Status in linux-oem-5.17 source package in Jammy: Fix Committed Bug description: The fix is already in the upstream kernel v5.19-rc1, no need to send the patches to unstable kernel. And for Jammy kernel, this SRU depends on #1949245, after merging the patchset for #1949245, then could apply this SRU to jammy. [Impact] On the AMD YC platforms, the internal mic can't be detected and there is no internal mic for users to use. [Fix] Backport 2 patches from mainline kernel to fix this problem. [Test] boot the patched kernel on the machine which has updated BIOS, after loging into the desktop, open the gnome-sound-setting, there is internal mic, and could record sound via internal mic. [Where problems could occur] This only impacts intenal mic detection on AMD yc machines, it will check the acpi variable first, if not detected, it will check the acpi dmi table as before, so the regression possibility is very low, and we already tested these patches on a couple of Lenovo YC machines, all worked well. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1980700/+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 1967856] Re: Hairpin traffic does not work with centralized NAT gw
** Changed in: linux (Ubuntu Jammy) Status: Confirmed => Fix Committed ** Changed in: linux (Ubuntu Focal) Status: Confirmed => Fix Committed -- 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/1967856 Title: Hairpin traffic does not work with centralized NAT gw Status in linux package in Ubuntu: Invalid Status in openvswitch package in Ubuntu: Invalid Status in ovn package in Ubuntu: Invalid Status in linux source package in Focal: Fix Committed Status in openvswitch source package in Focal: Invalid Status in ovn source package in Focal: Invalid Status in linux source package in Impish: Won't Fix Status in openvswitch source package in Impish: New Status in ovn source package in Impish: New Status in linux source package in Jammy: Fix Committed Status in openvswitch source package in Jammy: Invalid Status in ovn source package in Jammy: Invalid Status in linux source package in Kinetic: Invalid Status in openvswitch source package in Kinetic: Invalid Status in ovn source package in Kinetic: Invalid Bug description: If you have two hvs where hv1 is the gateway chassis and you have an instance running on hv2. On instance on hv2 hairpin traffic works for the first session, but not for the next: $ ping -c1 10.78.95.89 PING 10.78.95.89 (10.78.95.89) 56(84) bytes of data. 64 bytes from 10.78.95.89: icmp_seq=1 ttl=62 time=1.07 ms --- 10.78.95.89 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.078/1.078/1.078/0.000 ms $ sudo ovs-appctl -t ovs-vswitchd dpctl/dump-conntrack icmp,orig=(src=10.78.95.89,dst=192.168.0.211,id=7334,type=8,code=0),reply=(src=192.168.0.211,dst=10.78.95.89,id=7334,type=0,code=0),zone=7 icmp,orig=(src=192.168.0.211,dst=10.78.95.89,id=7334,type=8,code=0),reply=(src=10.78.95.89,dst=192.168.0.211,id=7334,type=0,code=0),zone=7 $ ping -c1 10.78.95.89 PING 10.78.95.89 (10.78.95.89) 56(84) bytes of data. --- 10.78.95.89 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms $ sudo ovs-appctl -t ovs-vswitchd dpctl/dump-conntrack icmp,orig=(src=10.78.95.89,dst=192.168.0.211,id=7334,type=8,code=0),reply=(src=192.168.0.211,dst=10.78.95.89,id=7334,type=0,code=0),zone=7 icmp,orig=(src=192.168.0.211,dst=10.78.95.89,id=7334,type=8,code=0),reply=(src=10.78.95.89,dst=192.168.0.211,id=7334,type=0,code=0),zone=7 icmp,orig=(src=192.168.0.211,dst=10.78.95.89,id=7335,type=8,code=0),reply=(src=10.78.95.89,dst=192.168.0.211,id=7335,type=0,code=0),zone=7 We made an attempt at using OVN built with [0], but that did unfortunately not help. If we however revert [1] it works again: $ ping -c1 10.78.95.89 PING 10.78.95.89 (10.78.95.89) 56(84) bytes of data. 64 bytes from 10.78.95.89: icmp_seq=1 ttl=62 time=1.31 ms --- 10.78.95.89 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.318/1.318/1.318/0.000 ms $ sudo ovs-appctl -t ovs-vswitchd dpctl/dump-conntrack icmp,orig=(src=192.168.0.211,dst=10.78.95.89,id=7336,type=8,code=0),reply=(src=10.78.95.89,dst=192.168.0.211,id=7336,type=0,code=0),zone=7 icmp,orig=(src=10.78.95.89,dst=192.168.0.211,id=7336,type=8,code=0),reply=(src=192.168.0.211,dst=10.78.95.89,id=7336,type=0,code=0),zone=7 icmp,orig=(src=10.78.95.89,dst=192.168.0.211,id=7336,type=8,code=0),reply=(src=192.168.0.211,dst=10.78.95.89,id=7336,type=0,code=0),zone=1 $ ping -c1 10.78.95.89 PING 10.78.95.89 (10.78.95.89) 56(84) bytes of data. 64 bytes from 10.78.95.89: icmp_seq=1 ttl=62 time=0.307 ms --- 10.78.95.89 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.307/0.307/0.307/0.000 ms $ sudo ovs-appctl -t ovs-vswitchd dpctl/dump-conntrack icmp,orig=(src=10.78.95.89,dst=192.168.0.211,id=7337,type=8,code=0),reply=(src=192.168.0.211,dst=10.78.95.89,id=7337,type=0,code=0),zone=7 icmp,orig=(src=10.78.95.89,dst=192.168.0.211,id=7337,type=8,code=0),reply=(src=192.168.0.211,dst=10.78.95.89,id=7337,type=0,code=0),zone=1 icmp,orig=(src=192.168.0.211,dst=10.78.95.89,id=7337,type=8,code=0),reply=(src=10.78.95.89,dst=192.168.0.211,id=7337,type=0,code=0),zone=7 icmp,orig=(src=192.168.0.211,dst=10.78.95.89,id=7336,type=8,code=0),reply=(src=10.78.95.89,dst=192.168.0.211,id=7336,type=0,code=0),zone=7 icmp,orig=(src=10.78.95.89,dst=192.168.0.211,id=7336,type=8,code=0),reply=(src=192.168.0.211,dst=10.78.95.89,id=7336,type=0,code=0),zone=7 icmp,orig=(src=10.78.95.89,dst=192.168.0.211,id=7336,type=8,code=0),reply=(src=192.168.0.211,dst=10.78.95.89,id=7336,type=0,code=0),zone=1 0: https://patchwork.ozlabs.org/project/ovn/patch/20220401175516.2139179-1-mmich...@redhat.com/ 1: https://github.com/ovn-org/ovn/commit/4deac4509abbedd6ffaecf27eed01ddefccea40a --- Pro
[Kernel-packages] [Bug 1978820] Re: Jammy Charmed OpenStack deployment fails over connectivity issues when using converged OVS bridge for control and data planes
** Changed in: linux (Ubuntu Jammy) Status: In Progress => Fix Committed -- 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/1978820 Title: Jammy Charmed OpenStack deployment fails over connectivity issues when using converged OVS bridge for control and data planes Status in linux package in Ubuntu: Confirmed Status in linux source package in Jammy: Fix Committed Bug description: Platform: OpenStack Yoga, Ubuntu 22.04 Jammy, Kernel 5.15.0-37-generic Charmed Openstack deployment with HW Offload over Jammy series will look ok until Vault initialization phase, then after initializing Vault all DB-related apps will end up in block/error state over "Failed to connect to MYSQL". Connectivity testing between DB containers located on different nodes will show there is unexplained sporadic packet loss preventing proper communication between the DB related apps. This will happen when the following conditions are met: 1. Control plane (oam, internal spaces) is configured as vlan interfaces on the same OVS bridge used for data plane (over high speed NIC with HW Offload capabilities). 2. OVS was set with HW offload=true (will happen by OVN chrams after Vault initialization) 3. NIC was not yet set to "switchdev" mode (netplan file will be created by OVN chrams after Vault initialization, however will take affect only after node is rebooted) The root cause is the following missing kernel patch: https://patchwork.kernel.org/project/netdevbpf/patch/20220531205447.99236-3-sa...@kernel.org/ To reproduce: Deploy charmed openstack with HW offload while using control plane on the high speed NIC OVS bridge. Before initializing Vault login to one of the innoDB instances and ping the other 2 instances - all ok. Manually enable OVS HW Offload, ping will become inconsistent. Workaround: After the deployment bring-up phase, BEFORE enabling Vault, login to the nodes and manually create 150-charm-ovn.yaml (example below). Then reboot one node after another. When nodes recover proceed with Vault initialization to complete the deployment. #root@node3:/home/ubuntu# cat /etc/netplan/150-charm-ovn.yaml ### # [ WARNING ] # Configuration file maintained by Juju. Local changes may be overwritten. # Config managed by ovn-chassis charm ### network: version: 2 ethernets: ens1f0: virtual-function-count: 8 embedded-switch-mode: switchdev delay-virtual-functions-rebind: true ens1f1: virtual-function-count: 8 embedded-switch-mode: switchdev delay-virtual-functions-rebind: true --- ProblemType: Bug AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Jul 4 10:46 seq crw-rw 1 root audio 116, 33 Jul 4 10:46 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' CRDA: N/A CasperMD5CheckResult: unknown DistroRelease: Ubuntu 22.04 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' MachineType: HP ProLiant DL360 Gen9 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl icp Package: linux (not installed) PciMultimedia: ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcFB: 0 mgag200drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-40-generic root=UUID=db1801a9-daa1-4386-b2ec-c65a40bc5dd3 ro intel_iommu=on vfio_iommu_type1.allow_unsafe_interrupts=1 ProcVersionSignature: Ubuntu 5.15.0-40.43-generic 5.15.35 RelatedPackageVersions: linux-restricted-modules-5.15.0-40-generic N/A linux-backports-modules-5.15.0-40-generic N/A linux-firmware 20220329.git681281e4-0ubuntu3.2 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' Tags: jammy uec-images Uname: Linux 5.15.0-40-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: N/A _MarkForUpload: True dmi.bios.date: 03/05/2015 dmi.bios.release: 1.32 dmi.bios.vendor: HP dmi.bios.version: P89 dmi.chassis.type: 23 dmi.chassis.vendor: HP dmi.ec.firmware.release: 2.53 dmi.modalias: dmi:bvnHP:bvrP89:bd03/05/2015:br1.32:efr2.53:svnHP:pnProLiantDL360Gen9:pvr:cvnHP:ct23:cvr:sku755258-B21: dmi.product.family: ProLiant dmi.product.name: ProLiant DL360 Gen9 dmi.product.sku: 755258-B21 dmi.sys.vendor: HP To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1978820/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Un
[Kernel-packages] [Bug 1980087] Re: Fix PSR flickers on Intel TGL laptops + AUO panel
** Changed in: linux (Ubuntu Jammy) Status: Confirmed => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-oem-5.14 in Ubuntu. https://bugs.launchpad.net/bugs/1980087 Title: Fix PSR flickers on Intel TGL laptops + AUO panel Status in HWE Next: In Progress Status in linux package in Ubuntu: Fix Released Status in linux-oem-5.14 package in Ubuntu: Invalid Status in linux source package in Focal: Won't Fix Status in linux-oem-5.14 source package in Focal: Fix Committed Status in linux source package in Jammy: Fix Committed Status in linux-oem-5.14 source package in Jammy: Invalid Bug description: [Impact] Screen flickers on certain Intel TGL laptops + AUO panel. [Fix] Enable PSR2 selective fetch only for the specific case to minimize the regression risk. [Test] Screen flickers can no longer be observed on affected laptops. [Where problems could occur] The fix becomes very specific, so any other combination won't be affected at all. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1980087/+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 1966010] Re: Fix audio on Zbook Studio G9
** Changed in: linux (Ubuntu Jammy) Status: Confirmed => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-oem-5.14 in Ubuntu. https://bugs.launchpad.net/bugs/1966010 Title: Fix audio on Zbook Studio G9 Status in HWE Next: In Progress Status in linux package in Ubuntu: Confirmed Status in linux-oem-5.14 package in Ubuntu: Invalid Status in linux source package in Focal: Won't Fix Status in linux-oem-5.14 source package in Focal: Fix Released Status in linux source package in Jammy: Fix Committed Status in linux-oem-5.14 source package in Jammy: Invalid Bug description: [Impact] Cirrus Logic AMP still doesn't work on Zbook Studio G9. Moreoever, The audio mute LEDs stop working after the said SRU. [Fix] Correcly interpret the debounce time from ACPI to gpiolib, and apply the correct quirk for the audio mute LEDs. [Where problems could occur] It's possible that some hardwares rely on the "wrong" debounce time to work, however the fix is to increase the debounce time, so it's more forgiving than decreasing. The LED fix is only applied to one system, so it's specifi and won't cause too much trouble. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1966010/+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 1980951] Re: [UBUNTU 22.04] Kernel oops while removing device from cio_ignore list
** Changed in: linux (Ubuntu Jammy) Status: In Progress => Fix Committed -- 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/1980951 Title: [UBUNTU 22.04] Kernel oops while removing device from cio_ignore list Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Committed Bug description: SRU Justification: == [Impact] * A kernel Oops occurs when a device is removed from the cio_ignore list (that is used to hide ccw devices) on a system with non-I/O subchannels (e.g. SCM or CHSC subchannels). * As a result, previously ignored devices cannot be activated again, and new devices cannot be found. [Fix] * 0c3812c347bf 0c3812c347bfb0dc213556a195e79850c55702f5 "s390/cio: derive cdev information only for IO-subchannels" [Test Plan] * An IBM zSystems or LinuxONE LPAR with with non-I/O subchannels. * Ubuntu Server 22.04 LTS (with GA kernel 5.15) installed. * Define a cio_ignore list (to hide ccw devices). * Remove a device from the cio_ignore list. * Due to hardware requirements this test needs to be conducted by IBM. [Where problems could occur] * General problems may occur with ccw device activation/deactivation in case the new initialization is erroneous. * Issues may also have an impact on the type of ccw devices, and may no longer be limited to non-I/O subchannels. * Things could still go wrong in case cdev is still not properly derived from sch-type SUBCHANNEL_TYPE_IO. [Other Info] * The commit is upstream since kernel 5.16 (next-20220315). __ ---Problem Description from Peter--- A kernel oops occurs when a device is removed from the cio_ignore list on a system with non-I/O subchannels (e.g. SCM or CHSC subchannels). As a result, previously ignored devices cannot be activated, and new devices cannot be found. ---uname output--- Linux localhost 5.15.0-40-generic #43-Ubuntu SMP Wed Jun 15 12:53:53 UTC 2022 s390x s390x s390x GNU/Linux Machine Type = s390x ---Steps to Reproduce--- On an s390x-LPAR with non-I/O subchannels, remove a device from the cio_ignore list. Oops output: [ 51.597505] Unable to handle kernel pointer dereference in virtual kernel address space [ 51.597516] Failing address: 2081e99191e98000 TEID: 2081e99191e98803 [ 51.597520] Fault in home space mode while using kernel ASCE. [ 51.597524] AS:82adc007 R3:0024 [ 51.597665] Oops: 0038 ilc:3 [#1] SMP [ 51.597671] Modules linked in: scm_block chsc_sch vfio_ccw mdev vfio_iommu_type1 vfio eadm_sch sch_fq_codel dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua drm i2c_core drm_panel_orientation_quirks ip_tables x_tables btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_ xor async_tx xor raid6_pq libcrc32c raid1 raid0 linear pkey zcrypt crc32_vx_s390 ghash_s390 prng chacha_s390 libchacha aes_s390 des_s390 libdes qeth_l2 bridge stp llc zfcp qeth qdio scsi_transport_fc ccwgroup sha512_s390 sha256_s390 sha1_s390 sha_common [ 51.597735] CPU: 6 PID: 1418 Comm: cio_ignore Not tainted 5.15.0-40-generic #43-Ubuntu [ 51.597740] Hardware name: IBM 2964 NC9 702 (LPAR) [ 51.597742] Krnl PSW : 0704e0018000 81b0c632 (__unset_online+0x22/0x70) [ 51.597752]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 [ 51.597756] Krnl GPRS: 0001 004a3ca8 038007e49000 2081e99191e98528 [ 51.597760] 81b0c610 81b07f10 [ 51.597762]02aa 81b0c610 038007e49000 038007a6bc98 [ 51.597765]941f9200 03ffa8cf95e0 81818900 038007a6bbf8 [ 51.597773] Krnl Code: 81b0c624: a784000cbrc 8,81b0c63c [ 51.597773]81b0c628: e3303022ltg %r3,32(%r3) [ 51.597773] #81b0c62e: a7840007brc 8,81b0c63c [ 51.597773] >81b0c632: e3303212lt %r3,512(%r3) [ 51.597773]81b0c638: a7740007brc 7,81b0c646 [ 51.597773]81b0c63c: a729lghi%r2,0 [ 51.597773]81b0c640: c0f400089854brcl 15,81c1f6e8 [ 51.597773]81b0c646: ebeff0880024stmg %r14,%r15,136(%r15) [ 51.597818] Call Trace: [ 51.597820] [<81b0c632>] __unset_online+0x22/0x70 [ 51.597824] ([<818188e6>] bus_for_each_dev+0x66/0xc0) [ 51.597828] [<81b0e378>] css_schedule_eval_cond+0xe8/0x130 [ 51.597832] [<81b08062
[Kernel-packages] [Bug 1980951] Re: [UBUNTU 22.04] Kernel oops while removing device from cio_ignore list
** Changed in: ubuntu-z-systems Status: In Progress => Fix Committed -- 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/1980951 Title: [UBUNTU 22.04] Kernel oops while removing device from cio_ignore list Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Committed Bug description: SRU Justification: == [Impact] * A kernel Oops occurs when a device is removed from the cio_ignore list (that is used to hide ccw devices) on a system with non-I/O subchannels (e.g. SCM or CHSC subchannels). * As a result, previously ignored devices cannot be activated again, and new devices cannot be found. [Fix] * 0c3812c347bf 0c3812c347bfb0dc213556a195e79850c55702f5 "s390/cio: derive cdev information only for IO-subchannels" [Test Plan] * An IBM zSystems or LinuxONE LPAR with with non-I/O subchannels. * Ubuntu Server 22.04 LTS (with GA kernel 5.15) installed. * Define a cio_ignore list (to hide ccw devices). * Remove a device from the cio_ignore list. * Due to hardware requirements this test needs to be conducted by IBM. [Where problems could occur] * General problems may occur with ccw device activation/deactivation in case the new initialization is erroneous. * Issues may also have an impact on the type of ccw devices, and may no longer be limited to non-I/O subchannels. * Things could still go wrong in case cdev is still not properly derived from sch-type SUBCHANNEL_TYPE_IO. [Other Info] * The commit is upstream since kernel 5.16 (next-20220315). __ ---Problem Description from Peter--- A kernel oops occurs when a device is removed from the cio_ignore list on a system with non-I/O subchannels (e.g. SCM or CHSC subchannels). As a result, previously ignored devices cannot be activated, and new devices cannot be found. ---uname output--- Linux localhost 5.15.0-40-generic #43-Ubuntu SMP Wed Jun 15 12:53:53 UTC 2022 s390x s390x s390x GNU/Linux Machine Type = s390x ---Steps to Reproduce--- On an s390x-LPAR with non-I/O subchannels, remove a device from the cio_ignore list. Oops output: [ 51.597505] Unable to handle kernel pointer dereference in virtual kernel address space [ 51.597516] Failing address: 2081e99191e98000 TEID: 2081e99191e98803 [ 51.597520] Fault in home space mode while using kernel ASCE. [ 51.597524] AS:82adc007 R3:0024 [ 51.597665] Oops: 0038 ilc:3 [#1] SMP [ 51.597671] Modules linked in: scm_block chsc_sch vfio_ccw mdev vfio_iommu_type1 vfio eadm_sch sch_fq_codel dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua drm i2c_core drm_panel_orientation_quirks ip_tables x_tables btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_ xor async_tx xor raid6_pq libcrc32c raid1 raid0 linear pkey zcrypt crc32_vx_s390 ghash_s390 prng chacha_s390 libchacha aes_s390 des_s390 libdes qeth_l2 bridge stp llc zfcp qeth qdio scsi_transport_fc ccwgroup sha512_s390 sha256_s390 sha1_s390 sha_common [ 51.597735] CPU: 6 PID: 1418 Comm: cio_ignore Not tainted 5.15.0-40-generic #43-Ubuntu [ 51.597740] Hardware name: IBM 2964 NC9 702 (LPAR) [ 51.597742] Krnl PSW : 0704e0018000 81b0c632 (__unset_online+0x22/0x70) [ 51.597752]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 [ 51.597756] Krnl GPRS: 0001 004a3ca8 038007e49000 2081e99191e98528 [ 51.597760] 81b0c610 81b07f10 [ 51.597762]02aa 81b0c610 038007e49000 038007a6bc98 [ 51.597765]941f9200 03ffa8cf95e0 81818900 038007a6bbf8 [ 51.597773] Krnl Code: 81b0c624: a784000cbrc 8,81b0c63c [ 51.597773]81b0c628: e3303022ltg %r3,32(%r3) [ 51.597773] #81b0c62e: a7840007brc 8,81b0c63c [ 51.597773] >81b0c632: e3303212lt %r3,512(%r3) [ 51.597773]81b0c638: a7740007brc 7,81b0c646 [ 51.597773]81b0c63c: a729lghi%r2,0 [ 51.597773]81b0c640: c0f400089854brcl 15,81c1f6e8 [ 51.597773]81b0c646: ebeff0880024stmg %r14,%r15,136(%r15) [ 51.597818] Call Trace: [ 51.597820] [<81b0c632>] __unset_online+0x22/0x70 [ 51.597824] ([<818188e6>] bus_for_each_dev+0x66/0xc0) [ 51.597828] [<81b0e378>] css_schedule_eval_cond+0xe8/0x130 [ 51.597832] [<81b08062>]
[Kernel-packages] [Bug 1978333] Re: Remove "ata_piix.prefer_ms_hyperv=0" parameter
** Description changed: [Impact] Azure VM instances hit I/O error on boot causing kernel crash [Test Plan] + + + spin up azure vm + + sudo apt-get install azure-cli + + sudo apt install linux-crashdump + + reboot + + kdump-config show + + + DUMP_MODE:kdump + USE_KDUMP:1 + KDUMP_SYSCTL: kernel.panic_on_oops=1 + KDUMP_COREDIR:/var/crash + crashkernel addr: 0x +/var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-5.4.0-1085-azure + kdump initrd: +/var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-5.4.0-1085-azure + current state:ready to kdump + + kexec command: + /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-5.4.0-1085-azure root=UUID=a117a689-aa1d-4cdc-8a30-7b9fbf174437 ro console=tty1 console=ttyS0 earlyprintk=ttyS0 reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll nousb ata_piix.prefer_ms_hyperv=0" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz + + #verify kdump is on + + cat /proc/cmdline + crashkernel=512M-:192M + + dmesg | grep -i crash + [0.071660] kexec: Reserving the low 1M of memory for crashkernel + [0.269823] Reserving 192MB of memory at 640MB for crashkernel (System RAM: 4095MB) + + cat /proc/sys/kernel/sysrq + # make sure this value is greater than 0 + sudo sysctl -w kernel.sysrq=1 + + #set it to 1 + + # perform crash + sudo su + echo c > sysrq-trigger + + #kdump doesnt work on Azure and hangs indefiantly + #reboot VM + + Execute commands lxc launch ubuntu:impish kdumpimpish lxc exec kdumpimpish bash apt-get install kdump-tools -y Say (y) to all questions during install #A reboot is needed sudo reboot #print out the crashkernel config kdump-config test # Output shows the parameter "ata_piix.prefer_ms_hyperv=0" is not listed kdump-config test | grep "ata_piix.prefer_ms_hyperv=0" Full output of kdump-config test * no crashkernel= parameter in the kernel cmdline * Invalid symlink : /var/lib/kdump/initrd.img * Invalid symlink : /var/lib/kdump/vmlinuz * /etc/default/kdump-tools: KDUMP_KERNEL does not exist: /var/lib/kdump/vmlinuz USE_KDUMP:1 KDUMP_COREDIR:/var/crash crashkernel addr kdump kernel addr kdump kernel: /var/lib/kdump/vmlinuz kdump initrd: /var/lib/kdump/initrd.img kexec command to be used: /sbin/kexec -p --command-line="BOOT_IMAGE=/vmlinuz-5.13.0-48-generic root=/dev/mapper/vgubuntu-root ro quiet splash vt.handoff=7 reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll nousb" /var/lib/kdump/vmlinuz [Where Problems Could Occur] This change modifies the debian/rules. The package could fail to build properly if mistyped. [Other] Back-porting a fix from upstream to remove "ata_piix.prefer_ms_hyperv=0" parameter. target series - Kinetic-> Bionic upstream patch https://salsa.debian.org/debian/kdump- tools/-/commit/b1bac9396ddbbce3817c34be3161630698e4a503 *Note: There are two source packages needed changes, kdump-tools for Impish -> Kinetic and makedumpfile for series Focal -> Bionic ** Description changed: [Impact] Azure VM instances hit I/O error on boot causing kernel crash [Test Plan] - - spin up azure vm + spin up azure vm sudo apt-get install azure-cli sudo apt install linux-crashdump + Say (y) to all questions during install + reboot kdump-config show - DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: 0x -/var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-5.4.0-1085-azure - kdump initrd: -/var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-5.4.0-1085-azure + /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-5.4.0-1085-azure + kdump initrd: + /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-5.4.0-1085-azure current state:ready to kdump kexec command: - /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-5.4.0-1085-azure root=UUID=a117a689-aa1d-4cdc-8a30-7b9fbf174437 ro console=tty1 console=ttyS0 earlyprintk=ttyS0 reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll nousb ata_piix.prefer_ms_hyperv=0" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz + /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-5.4.0-1085-azure root=UUID=a117a689-aa1d-4cdc-8a30-7b9fbf174437 ro console=tty1 console=ttyS0 earlyprintk=ttyS0 reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll nousb ata_piix.prefer_ms_hyperv=0" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz #verify kdump is on cat /proc/cmdline crashkernel=512M-:192M dmesg | grep -i crash [0.071660] kexec: Reserving the low 1M of memory for crashkernel [0.269823] Reserving 192MB of memory at 640MB for crashkernel (Sy
[Kernel-packages] [Bug 1980951] Comment bridged from LTC Bugzilla
--- Comment From peter.oberparlei...@de.ibm.com 2022-07-08 13:23 EDT--- (In reply to comment #7) > A patched jammy kernel 5.15 test build in PPA is available here: > https://launchpad.net/~fheimes/+archive/ubuntu/lp1980951 I successfully verified that the PPA kernel fixes the problem: Without fix === root@localhost:~# uname -a Linux localhost 5.15.0-40-generic #43-Ubuntu SMP Wed Jun 15 12:53:53 UTC 2022 s390x s390x s390x GNU/Linux root@localhost:~# lscss | wc -l 6 root@localhost:~# dmesg -c >/dev/null root@localhost:~# echo free all >/proc/cio_ignore root@localhost:~# dmesg | head -n 5 [ 91.836284] Unable to handle kernel pointer dereference in virtual kernel address space [ 91.836300] Failing address: 637075383700 TEID: 6370753837000803 [ 91.836305] Fault in home space mode while using kernel ASCE. [ 91.836311] AS:0a9e8007 R3:0024 [ 91.836494] Oops: 0038 ilc:3 [#1] SMP root@localhost:~# lscss | wc -l 6 With fix applied root@localhost:~# uname -a Linux localhost 5.15.0-41-generic #44~lp1980951-Ubuntu SMP Thu Jul 7 14:31:02 UTC 2022 s390x s390x s390x GNU/Linux root@localhost:~# lscss | wc -l 6 root@localhost:~# dmesg -c >/dev/null root@localhost:~# echo free all >/proc/cio_ignore root@localhost:~# dmesg root@localhost:~# lscss | wc -l 2961 -- 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/1980951 Title: [UBUNTU 22.04] Kernel oops while removing device from cio_ignore list Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Committed Bug description: SRU Justification: == [Impact] * A kernel Oops occurs when a device is removed from the cio_ignore list (that is used to hide ccw devices) on a system with non-I/O subchannels (e.g. SCM or CHSC subchannels). * As a result, previously ignored devices cannot be activated again, and new devices cannot be found. [Fix] * 0c3812c347bf 0c3812c347bfb0dc213556a195e79850c55702f5 "s390/cio: derive cdev information only for IO-subchannels" [Test Plan] * An IBM zSystems or LinuxONE LPAR with with non-I/O subchannels. * Ubuntu Server 22.04 LTS (with GA kernel 5.15) installed. * Define a cio_ignore list (to hide ccw devices). * Remove a device from the cio_ignore list. * Due to hardware requirements this test needs to be conducted by IBM. [Where problems could occur] * General problems may occur with ccw device activation/deactivation in case the new initialization is erroneous. * Issues may also have an impact on the type of ccw devices, and may no longer be limited to non-I/O subchannels. * Things could still go wrong in case cdev is still not properly derived from sch-type SUBCHANNEL_TYPE_IO. [Other Info] * The commit is upstream since kernel 5.16 (next-20220315). __ ---Problem Description from Peter--- A kernel oops occurs when a device is removed from the cio_ignore list on a system with non-I/O subchannels (e.g. SCM or CHSC subchannels). As a result, previously ignored devices cannot be activated, and new devices cannot be found. ---uname output--- Linux localhost 5.15.0-40-generic #43-Ubuntu SMP Wed Jun 15 12:53:53 UTC 2022 s390x s390x s390x GNU/Linux Machine Type = s390x ---Steps to Reproduce--- On an s390x-LPAR with non-I/O subchannels, remove a device from the cio_ignore list. Oops output: [ 51.597505] Unable to handle kernel pointer dereference in virtual kernel address space [ 51.597516] Failing address: 2081e99191e98000 TEID: 2081e99191e98803 [ 51.597520] Fault in home space mode while using kernel ASCE. [ 51.597524] AS:82adc007 R3:0024 [ 51.597665] Oops: 0038 ilc:3 [#1] SMP [ 51.597671] Modules linked in: scm_block chsc_sch vfio_ccw mdev vfio_iommu_type1 vfio eadm_sch sch_fq_codel dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua drm i2c_core drm_panel_orientation_quirks ip_tables x_tables btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_ xor async_tx xor raid6_pq libcrc32c raid1 raid0 linear pkey zcrypt crc32_vx_s390 ghash_s390 prng chacha_s390 libchacha aes_s390 des_s390 libdes qeth_l2 bridge stp llc zfcp qeth qdio scsi_transport_fc ccwgroup sha512_s390 sha256_s390 sha1_s390 sha_common [ 51.597735] CPU: 6 PID: 1418 Comm: cio_ignore Not tainted 5.15.0-40-generic #43-Ubuntu [ 51.597740] Hardware name: IBM 2964 NC9 702 (LPAR) [ 51.597742] Krnl PSW : 0704e0018000 81b0c632 (__unset_online+0x22/0x70) [ 51.597752]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 [ 51.597756] Krnl GPRS: 0001 004a3ca8 038007e49000 2081e99191e98528 [ 51.597760]000
[Kernel-packages] [Bug 1981105] [NEW] i2c-mlxbf.c: support lock mechanism
Public bug reported: SRU Justification: [Impact] Support the I2C lock mechanism, otherwise there could be unexpected behavior when the i2c driver is accessed by several entities like the linux driver, ATF driver and UEFI driver. [Fix] * Support lock and unlock * replace ioremap_nocache with ioremap [Test Case] * Make sure the i2c-mlxbf.c driver is loaded and /dev/i2c-1 is created * check that ipmitool from the BF->BMC and from the BMC->BF work (this only applies on boards with a BMC of course) [Regression Potential] Any of the test cases above could be impacted due to these changes. ** Affects: linux-bluefield (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-bluefield in Ubuntu. https://bugs.launchpad.net/bugs/1981105 Title: i2c-mlxbf.c: support lock mechanism Status in linux-bluefield package in Ubuntu: New Bug description: SRU Justification: [Impact] Support the I2C lock mechanism, otherwise there could be unexpected behavior when the i2c driver is accessed by several entities like the linux driver, ATF driver and UEFI driver. [Fix] * Support lock and unlock * replace ioremap_nocache with ioremap [Test Case] * Make sure the i2c-mlxbf.c driver is loaded and /dev/i2c-1 is created * check that ipmitool from the BF->BMC and from the BMC->BF work (this only applies on boards with a BMC of course) [Regression Potential] Any of the test cases above could be impacted due to these changes. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1981105/+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 1981105] Re: i2c-mlxbf.c: support lock mechanism
** Description changed: SRU Justification: [Impact] Support the I2C lock mechanism, otherwise there could be unexpected - behavior when the i2c driver is accessed by several entities like the - linux driver, ATF driver and UEFI driver. + behavior when an i2c bus is accessed by several entities like the linux + driver, ATF driver and UEFI driver. Replace ioremap_cache with ioremap + since it is deprecated in later kernels. [Fix] * Support lock and unlock * replace ioremap_nocache with ioremap [Test Case] * Make sure the i2c-mlxbf.c driver is loaded and /dev/i2c-1 is created * check that ipmitool from the BF->BMC and from the BMC->BF work (this only applies on boards with a BMC of course) [Regression Potential] Any of the test cases above could be impacted due to these changes. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-bluefield in Ubuntu. https://bugs.launchpad.net/bugs/1981105 Title: i2c-mlxbf.c: support lock mechanism Status in linux-bluefield package in Ubuntu: New Bug description: SRU Justification: [Impact] Support the I2C lock mechanism, otherwise there could be unexpected behavior when an i2c bus is accessed by several entities like the linux driver, ATF driver and UEFI driver. Replace ioremap_cache with ioremap since it is deprecated in later kernels. [Fix] * Support lock and unlock * replace ioremap_nocache with ioremap [Test Case] * Make sure the i2c-mlxbf.c driver is loaded and /dev/i2c-1 is created * check that ipmitool from the BF->BMC and from the BMC->BF work (this only applies on boards with a BMC of course) [Regression Potential] Any of the test cases above could be impacted due to these changes. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1981105/+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 1786013] Autopkgtest regression report (linux-meta-gcp/5.4.0.1083.88)
All autopkgtests for the newly accepted linux-meta-gcp (5.4.0.1083.88) for focal have finished running. The following regressions have been reported in tests triggered by the package: r8168/8.048.00-1ubuntu0.20.04.2 (amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/focal/update_excuses.html#linux-meta-gcp [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-azure in Ubuntu. https://bugs.launchpad.net/bugs/1786013 Title: Packaging resync Status in linux package in Ubuntu: Fix Released Status in linux-azure package in Ubuntu: Fix Released Status in linux-azure-edge package in Ubuntu: Fix Released Status in linux source package in Precise: Fix Released Status in linux-azure source package in Precise: Won't Fix Status in linux-azure-edge source package in Precise: Won't Fix Status in linux source package in Trusty: Fix Released Status in linux-azure source package in Trusty: Fix Released Status in linux-azure-edge source package in Trusty: Won't Fix Status in linux source package in Xenial: Fix Released Status in linux-azure source package in Xenial: Fix Released Status in linux-azure-edge source package in Xenial: Fix Released Status in linux source package in Bionic: Fix Released Status in linux-azure source package in Bionic: Fix Released Status in linux-azure-edge source package in Bionic: Fix Released Status in linux source package in Cosmic: Fix Released Status in linux-azure source package in Cosmic: Fix Released Status in linux-azure-edge source package in Cosmic: Won't Fix Status in linux source package in Disco: Fix Released Status in linux-azure source package in Disco: Fix Released Status in linux-azure-edge source package in Disco: Won't Fix Bug description: Ongoing packing resyncs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1786013/+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 1980884] Re: ubuntu guest kernel panics when a sev guest with passthrough mlx5 VF is used
** Description changed: Guest kernel panic can be observed when Ubuntu SEV guest with mlx5 vfio-pci is started as iperf3 server using "iperf3 -s" and as soon as the client tries to connect with it. Steps to reproduce: HOST INFO Host type : OCI (Oracle Cloud) Bare-Metal Server Server/Machine: ORACLE SERVER E4-2c CPU model : AMD EPYC 7J13 64-Core Processor Architecture : x86_64 Host OS : Oracle Linux Server release 7.9 Host Kernel : 5.4.17-2136.309.3.el7uek.x86_64 #2 SMP Tue Jun 14 21:58:29 PDT 2022 Hypervisor: QEMU emulator version 4.2.1 (qemu-4.2.1-17.1.oci.el7) OVMF/AAVMF: OVMF-1.6.2-2.el7.noarch libiscsi : libiscsi-1.19.0-1.oci.el7.x86_64 Guest Kernel : 5.11.0-1028-ORACLE - 1) Start Ubuntu 20.04/18.04 SEV guest with vfio-pci: /usr/bin/qemu-system-x86_64 -machine q35 -name OL20.04-uefi -enable-kvm -nodefaults -cpu host,+host-phys-bits -m 8G -smp 8,maxcpus=240 -monitor stdio -vnc 0.0.0.0:0,to=999 -vga std -drive file=/usr/share/OVMF/OVMF_CODE.pure-efi.fd,index=0,if=pflash,format=raw,readonly -drive file=OVMF_VARS.pure-efi.fd.ol20.04,index=1,if=pflash,format=raw -device virtio-scsi-pci,id=virtio-scsi-pci0,disable-legacy=on,iommu_platform=true - -fw_cfg name=opt/ovmf/OCI-ENABLE,string=0x1 -drive + -drive file=/systest/atanveer/scripts/Ubuntu-20.04-2022.02.15-0-uefi-x86_64.qcow2,if=none,id=local_disk0,format=qcow2,media=disk -device ide-hd,drive=local_disk0,id=local_disk1,bootindex=0 -net none -device vfio-pci,host=:21:10.1 -qmp tcp:127.0.0.1:3334,server,nowait -serial telnet:127.0.0.1:,server,nowait -D ./OL20.04-uefi.log -device virtio-rng-pci,disable-legacy=on,iommu_platform=true -object sev-guest,id=sev0,cbitpos=51,reduced-phys-bits=1 -machine memory-encryption=sev0 2) Start a client guest OL/Ubuntu: /usr/bin/qemu-system-x86_64 -machine q35 -name OL18.04-uefi -enable-kvm -nodefaults -cpu host,+host-phys-bits -m 8G -smp 8,maxcpus=240 -monitor stdio -vnc 0.0.0.0:0,to=999 -vga std -drive file=/usr/share/OVMF/OVMF_CODE.pure-efi.fd,index=0,if=pflash,format=raw,readonly -drive file=OVMF_VARS.pure-efi.fd.ol18.04,index=1,if=pflash,format=raw -device virtio-scsi-pci,id=virtio-scsi-pci0,disable-legacy=on,iommu_platform=true - -fw_cfg name=opt/ovmf/OCI-ENABLE,string=0x1 -drive + -drive file=/systest/atanveer/scripts/Ubuntu-18.04-2022.02.13-0-uefi-x86_64.qcow2,if=none,id=local_disk0,format=qcow2,media=disk -device ide-hd,drive=local_disk0,id=local_disk1,bootindex=0 -net none -device vfio-pci,host=:21:10.2 -qmp tcp:127.0.0.1:,server,nowait -serial telnet:127.0.0.1:,server,nowait -D ./OL18.04-uefi.log -device virtio-rng-pci,disable-legacy=on,iommu_platform=true -object sev-guest,id=sev0,cbitpos=51,reduced-phys-bits=1 -machine memory-encryption=sev0 3) Flush iptables on both the VMs using "iptables -F" 4) Start the iperf3 server on the first VM using "iperf3 -s" 5) Start the iperf3 client on the second VM using "iperf3 -c -4 -f M -i 0 -t 70 -O 10 -P 64" The kernel panic is seen on the first VM i.e. Ubuntu 20.04 with iperf3 also showing "Bad Address" error. - Console logs: root@ubuntu-20-04:~# iperf3 -s --- Server listening on 5201 --- Accepted connection from 10.196.246.104, port 33732 [ 5] local 10.196.247.88 port 5201 connected to 10.196.246.104 port 33734 [ 8] local 10.196.247.88 port 5201 connected to 10.196.246.104 port 33736 [ 10] local 10.196.247.88 port 5201 connected to 10.196.246.104 port 33738 iperf3: error - unable to read from stream socket: Bad address --- Server listening on 5201 --- [ 91.083856] general protection fault: [#1] SMP NOPTI [ 91.084591] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 5.11.0-1028-oracle #31~20.04.1-Ubuntu [ 91.085393] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.6.2 06/01/2022 [ 91.086205] RIP: 0010:memcpy_erms+0x6/0x10 [ 91.086640] Code: cc cc cc cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe [ 91.088559] RSP: 0018:a9c1408e4b60 EFLAGS: 00010282 [ 91.089105] RAX: 938cd8e48000 RBX: 1000 RCX: 1000 [ 91.089843] RDX: 1000 RSI: bb62fcf4fd5bf3d6 RDI: 938cd8e48000 [ 91.090578] RBP: a9c1408e4c00 R08: ef2745639200 R09: [ 91.091309] R10: ef27456399c8 R11: 4209 R12: 1000 [ 91.092043] R13: ef2745639200 R14: 1000 R15: 0d558380 [ 91.092782] FS: () GS:938df430(
[Kernel-packages] [Bug 1980884] Re: ubuntu guest kernel panics when a sev guest with passthrough mlx5 VF is used
** Description changed: Guest kernel panic can be observed when Ubuntu SEV guest with mlx5 vfio-pci is started as iperf3 server using "iperf3 -s" and as soon as the client tries to connect with it. Steps to reproduce: HOST INFO Host type : OCI (Oracle Cloud) Bare-Metal Server Server/Machine: ORACLE SERVER E4-2c CPU model : AMD EPYC 7J13 64-Core Processor Architecture : x86_64 Host OS : Oracle Linux Server release 7.9 Host Kernel : 5.4.17-2136.309.3.el7uek.x86_64 #2 SMP Tue Jun 14 21:58:29 PDT 2022 - Hypervisor: QEMU emulator version 4.2.1 (qemu-4.2.1-17.1.oci.el7) + Hypervisor: QEMU emulator version 4.2.1 (qemu-4.2.1-17.1.el7) OVMF/AAVMF: OVMF-1.6.2-2.el7.noarch - libiscsi : libiscsi-1.19.0-1.oci.el7.x86_64 + libiscsi : libiscsi-1.19.0-1.el7.x86_64 Guest Kernel : 5.11.0-1028-ORACLE 1) Start Ubuntu 20.04/18.04 SEV guest with vfio-pci: /usr/bin/qemu-system-x86_64 -machine q35 -name OL20.04-uefi -enable-kvm -nodefaults -cpu host,+host-phys-bits -m 8G -smp 8,maxcpus=240 -monitor stdio -vnc 0.0.0.0:0,to=999 -vga std -drive file=/usr/share/OVMF/OVMF_CODE.pure-efi.fd,index=0,if=pflash,format=raw,readonly -drive file=OVMF_VARS.pure-efi.fd.ol20.04,index=1,if=pflash,format=raw -device virtio-scsi-pci,id=virtio-scsi-pci0,disable-legacy=on,iommu_platform=true -drive file=/systest/atanveer/scripts/Ubuntu-20.04-2022.02.15-0-uefi-x86_64.qcow2,if=none,id=local_disk0,format=qcow2,media=disk -device ide-hd,drive=local_disk0,id=local_disk1,bootindex=0 -net none -device vfio-pci,host=:21:10.1 -qmp tcp:127.0.0.1:3334,server,nowait -serial telnet:127.0.0.1:,server,nowait -D ./OL20.04-uefi.log -device virtio-rng-pci,disable-legacy=on,iommu_platform=true -object sev-guest,id=sev0,cbitpos=51,reduced-phys-bits=1 -machine memory-encryption=sev0 2) Start a client guest OL/Ubuntu: /usr/bin/qemu-system-x86_64 -machine q35 -name OL18.04-uefi -enable-kvm -nodefaults -cpu host,+host-phys-bits -m 8G -smp 8,maxcpus=240 -monitor stdio -vnc 0.0.0.0:0,to=999 -vga std -drive file=/usr/share/OVMF/OVMF_CODE.pure-efi.fd,index=0,if=pflash,format=raw,readonly -drive file=OVMF_VARS.pure-efi.fd.ol18.04,index=1,if=pflash,format=raw -device virtio-scsi-pci,id=virtio-scsi-pci0,disable-legacy=on,iommu_platform=true -drive file=/systest/atanveer/scripts/Ubuntu-18.04-2022.02.13-0-uefi-x86_64.qcow2,if=none,id=local_disk0,format=qcow2,media=disk -device ide-hd,drive=local_disk0,id=local_disk1,bootindex=0 -net none -device vfio-pci,host=:21:10.2 -qmp tcp:127.0.0.1:,server,nowait -serial telnet:127.0.0.1:,server,nowait -D ./OL18.04-uefi.log -device virtio-rng-pci,disable-legacy=on,iommu_platform=true -object sev-guest,id=sev0,cbitpos=51,reduced-phys-bits=1 -machine memory-encryption=sev0 3) Flush iptables on both the VMs using "iptables -F" 4) Start the iperf3 server on the first VM using "iperf3 -s" 5) Start the iperf3 client on the second VM using "iperf3 -c -4 -f M -i 0 -t 70 -O 10 -P 64" The kernel panic is seen on the first VM i.e. Ubuntu 20.04 with iperf3 also showing "Bad Address" error. Console logs: root@ubuntu-20-04:~# iperf3 -s --- Server listening on 5201 --- Accepted connection from 10.196.246.104, port 33732 [ 5] local 10.196.247.88 port 5201 connected to 10.196.246.104 port 33734 [ 8] local 10.196.247.88 port 5201 connected to 10.196.246.104 port 33736 [ 10] local 10.196.247.88 port 5201 connected to 10.196.246.104 port 33738 iperf3: error - unable to read from stream socket: Bad address --- Server listening on 5201 --- [ 91.083856] general protection fault: [#1] SMP NOPTI [ 91.084591] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 5.11.0-1028-oracle #31~20.04.1-Ubuntu [ 91.085393] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.6.2 06/01/2022 [ 91.086205] RIP: 0010:memcpy_erms+0x6/0x10 [ 91.086640] Code: cc cc cc cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe [ 91.088559] RSP: 0018:a9c1408e4b60 EFLAGS: 00010282 [ 91.089105] RAX: 938cd8e48000 RBX: 1000 RCX: 1000 [ 91.089843] RDX: 1000 RSI: bb62fcf4fd5bf3d6 RDI: 938cd8e48000 [ 91.090578] RBP: a9c1408e4c00 R08: ef2745639200 R09: [ 91.091309] R10: ef27456399c8 R11: 4209 R12: 1000 [ 91.092043] R13: ef2745639200 R14: 1000 R15: 0d558380 [ 91.092782] FS: () GS:938df430
[Kernel-packages] [Bug 1942935] Re: kernel io hangs during mdcheck/resync
I believe to resolve the deadlock you want to do: echo active > /sys/block/md1/md/array_state Not "idle". You should see a hung task for mdcheck in there somewhere as well, and it only occurs when the raid is resyncing (md_resync should be running), at least for me I the workaround in comment 5: https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.11/+bug/1942935/comments/5 Haven't had a problem since, upgraded to 22.04 since then as well with 5.15. I am pretty sure the problem is still there, the problem surfaced in 20.04 when they changed the raid consistency check. The new check pauses the check after 8 hours and triggers the deadlock, I just let it run to completion like it did in 18.04. I have not checked the patches, but it's possible you have a different problem because I don't see in either of two hung process traces any calls to md_ code. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed-hwe-5.11 in Ubuntu. https://bugs.launchpad.net/bugs/1942935 Title: kernel io hangs during mdcheck/resync Status in linux package in Ubuntu: Confirmed Status in linux-signed-hwe-5.11 package in Ubuntu: Confirmed Bug description: It seems to always occur during an mdcheck/resync, if I am logged in via SSH it is still somewhat responsive and basic utilities like dmesg will work. But it apppears any write I/O will hang the terminal and nothing is written to syslog (presumably because it is blocked). Below is output of dmesg and cat /proc/mdstat, it appears the data check was interrupted and /proc/mdstat still shows progress, and a whole slew of hung tasks including md1_resync itself. [756484.534293] md: data-check of RAID array md0 [756484.628039] md: delaying data-check of md1 until md0 has finished (they share one or more physical units) [756493.808773] md: md0: data-check done. [756493.829760] md: data-check of RAID array md1 [778112.446410] md: md1: data-check interrupted. [810654.608102] md: data-check of RAID array md1 [832291.201064] md: md1: data-check interrupted. [899745.389485] md: data-check of RAID array md1 [921395.835305] md: md1: data-check interrupted. [921588.558834] INFO: task systemd-journal:376 blocked for more than 120 seconds. [921588.558846] Not tainted 5.11.0-27-generic #29~20.04.1-Ubuntu [921588.558850] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [921588.558854] task:systemd-journal state:D stack:0 pid: 376 ppid: 1 flags:0x0220 [921588.558859] Call Trace: [921588.558864] __schedule+0x44c/0x8a0 [921588.558872] schedule+0x4f/0xc0 [921588.558876] md_write_start+0x150/0x240 [921588.558880] ? wait_woken+0x80/0x80 [921588.558886] raid5_make_request+0x88/0x890 [raid456] [921588.558898] ? wait_woken+0x80/0x80 [921588.558901] ? mempool_kmalloc+0x17/0x20 [921588.558904] md_handle_request+0x12d/0x1a0 [921588.558907] ? __part_start_io_acct+0x51/0xf0 [921588.558912] md_submit_bio+0xca/0x100 [921588.558915] submit_bio_noacct+0x112/0x4f0 [921588.558918] ? ext4_fc_reserve_space+0x110/0x230 [921588.558922] submit_bio+0x51/0x1a0 [921588.558925] ? _cond_resched+0x19/0x30 [921588.558928] ? kmem_cache_alloc+0x38e/0x440 [921588.558932] ? ext4_init_io_end+0x1f/0x50 [921588.558936] ext4_io_submit+0x4d/0x60 [921588.558940] ext4_writepages+0x2c6/0xcd0 [921588.558944] do_writepages+0x43/0xd0 [921588.558948] ? do_writepages+0x43/0xd0 [921588.558951] ? fault_dirty_shared_page+0xa5/0x110 [921588.558955] __filemap_fdatawrite_range+0xcc/0x110 [921588.558960] file_write_and_wait_range+0x74/0xc0 [921588.558962] ext4_sync_file+0xf5/0x350 [921588.558967] vfs_fsync_range+0x49/0x80 [921588.558970] do_fsync+0x3d/0x70 [921588.558973] __x64_sys_fsync+0x14/0x20 [921588.558976] do_syscall_64+0x38/0x90 [921588.558980] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [921588.558984] RIP: 0033:0x7f4c97ee832b [921588.558987] RSP: 002b:7ffdceb29e50 EFLAGS: 0293 ORIG_RAX: 004a [921588.558991] RAX: ffda RBX: 55ced34b0fa0 RCX: 7f4c97ee832b [921588.558993] RDX: 7f4c97fc8000 RSI: 55ced3487b70 RDI: 0021 [921588.558995] RBP: 0001 R08: R09: 7ffdceb29fa8 [921588.558996] R10: 7f4c97d2c848 R11: 0293 R12: 7ffdceb29fa8 [921588.558998] R13: 7ffdceb29fa0 R14: 55ced34b0fa0 R15: 55ced34bcf90 [921588.559014] INFO: task mysqld:1505 blocked for more than 120 seconds. [921588.559018] Not tainted 5.11.0-27-generic #29~20.04.1-Ubuntu [921588.559022] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [921588.559025] task:mysqld state:D stack:0 pid: 1505 ppid: 1 flags:0x [921588.559030] Call Trace: [921588.559032] __schedule+0x44c/0x8a0 [921588.559036] schedule+0x4f/0xc0 [921588.559
[Kernel-packages] [Bug 1981111] [NEW] Focal update: v5.4.196 upstream stable release
Public bug reported: SRU Justification Impact: The upstream process for stable tree updates is quite similar in scope to the Ubuntu SRU process, e.g., each patch has to demonstrably fix a bug, and each patch is vetted by upstream by originating either directly from a mainline/stable Linux tree or a minimally backported form of that patch. The following upstream stable patches should be included in the Ubuntu kernel: v5.4.196 upstream stable release from git://git.kernel.org/ x86/xen: Make the boot CPU idle task reliable x86/xen: Make the secondary CPU idle tasks reliable rtc: fix use-after-free on device removal um: Cleanup syscall_handler_t definition/cast, fix warning Input: add bounds checking to input_set_capability() Input: stmfts - fix reference leak in stmfts_input_open crypto: stm32 - fix reference leak in stm32_crc_remove crypto: x86/chacha20 - Avoid spurious jumps to other functions ALSA: hda/realtek: Enable headset mic on Lenovo P360 nvme-multipath: fix hang when disk goes live over reconnect rtc: mc146818-lib: Fix the AltCentury for AMD platforms MIPS: lantiq: check the return value of kzalloc() drbd: remove usage of list iterator variable after loop platform/chrome: cros_ec_debugfs: detach log reader wq from devm ARM: 9191/1: arm/stacktrace, kasan: Silence KASAN warnings in unwind_frame() nilfs2: fix lockdep warnings in page operations for btree nodes nilfs2: fix lockdep warnings during disk space reclamation mmc: core: Specify timeouts for BKOPS and CACHE_FLUSH for eMMC mmc: block: Use generic_cmd6_time when modifying INAND_CMD38_ARG_EXT_CSD mmc: core: Default to generic_cmd6_time as timeout in __mmc_switch() SUNRPC: Clean up scheduling of autoclose SUNRPC: Prevent immediate close+reconnect SUNRPC: Don't call connect() more than once on a TCP socket ALSA: wavefront: Proper check of get_user() error perf: Fix sys_perf_event_open() race against self Fix double fget() in vhost_net_set_backend() PCI/PM: Avoid putting Elo i2 PCIe Ports in D3cold KVM: x86/mmu: Update number of zapped pages even if page list is stable crypto: qcom-rng - fix infinite loop on requests not multiple of WORD_SZ drm/dp/mst: fix a possible memory leak in fetch_monitor_name() dma-buf: fix use of DMA_BUF_SET_NAME_{A,B} in userspace ARM: dts: aspeed-g6: remove FWQSPID group in pinctrl dtsi ARM: dts: aspeed-g6: fix SPI1/SPI2 quad pin group net: macb: Increment rx bd head after allocating skb and buffer net/sched: act_pedit: sanitize shift argument before usage net: vmxnet3: fix possible use-after-free bugs in vmxnet3_rq_alloc_rx_buf() net: vmxnet3: fix possible NULL pointer dereference in vmxnet3_rq_cleanup() ice: fix possible under reporting of ethtool Tx and Rx statistics clk: at91: generated: consider range when calculating best rate net/qla3xxx: Fix a test in ql_reset_work() NFC: nci: fix sleep in atomic context bugs caused by nci_skb_alloc net/mlx5e: Properly block LRO when XDP is enabled ARM: 9196/1: spectre-bhb: enable for Cortex-A15 ARM: 9197/1: spectre-bhb: fix loop8 sequence for Thumb2 igb: skip phy status check where unavailable net: bridge: Clear offload_fwd_mark when passing frame up bridge interface. gpio: gpio-vf610: do not touch other bits when set the target bit gpio: mvebu/pwm: Refuse requests with inverted polarity perf bench numa: Address compiler error on s390 scsi: qla2xxx: Fix missed DMA unmap for aborted commands mac80211: fix rx reordering with non explicit / psmp ack policy selftests: add ping test with ping_group_range tuned ethernet: tulip: fix missing pci_disable_device() on error in tulip_init_one() net: stmmac: fix missing pci_disable_device() on error in stmmac_pci_probe() net: atlantic: verify hw_head_ lies within TX buffer ring Input: ili210x - fix reset timing block: return ELEVATOR_DISCARD_MERGE if possible net: stmmac: disable Split Header (SPH) for Intel platforms firmware_loader: use kernel credentials when reading firmware ARM: dts: imx7: Use audio_mclk_post_div instead audio_mclk_root_clk Reinstate some of "swiotlb: rework "fix info leak with DMA_FROM_DEVICE"" x86/xen: fix booting 32-bit pv guest x86/xen: Mark cpu_bringup_and_idle() as dead_end_function i2c: mt7621: fix missing clk_disable_unprepare() on error in mtk_i2c_probe() afs: Fix afs_getattr() to refetch file status if callback break occurred Linux 5.4.196 UBUNTU: Upstream stable to v5.4.196 ** Affects: linux (Ubuntu) Importance: Undecided Status: Invalid ** Affects: linux (Ubuntu Focal) Importance: Medium Assignee: Kamal Mostafa (kamalmostafa) Status: In Progress ** Tags: kernel-stable-tracking-bug ** Changed in: linux (Ubuntu) Status: New => Confirmed ** Tags added: kernel-stable-tracking-bug ** Also affects: linux (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: linux (Ubuntu) Status: Confirmed => Invalid ** Changed in: linux (Ubuntu Focal) Status: New => In Progress ** Chang
[Kernel-packages] [Bug 1971193] Re: Server Crash while running IO and switch port bounce test with 2K login session
[Expired for linux (Ubuntu) because there has been no activity for 60 days.] ** Changed in: linux (Ubuntu) Status: Incomplete => Expired -- 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/1971193 Title: Server Crash while running IO and switch port bounce test with 2K login session Status in linux package in Ubuntu: Expired Bug description: [Impact] Server crash and Call trace reported on one of the servers running IO and switch port bounce test from the 2K login session configuration. Call Trace: [56048.470488] Call Trace: [56048.470489] _raw_spin_lock_irqsave+0x32/0x40 [56048.470489] lpfc_dmp_dbg.part.32+0x28/0x220 [lpfc] [56048.470490] lpfc_cmpl_els_fdisc+0x145/0x460 [lpfc] [56048.470490] lpfc_sli_cancel_jobs+0x92/0xd0 [lpfc] [56048.470490] lpfc_els_flush_cmd+0x43c/0x670 [lpfc] [56048.470491] lpfc_els_flush_all_cmd+0x37/0x60 [lpfc] [56048.470491] lpfc_sli4_async_event_proc+0x956/0x1720 [lpfc] [56048.470492] lpfc_do_work+0x1485/0x1d70 [lpfc] [56048.470492] ? __schedule+0x280/0x700 [56048.470492] ? finish_wait+0x80/0x80 [56048.470493] ? lpfc_unregister_unused_fcf+0x80/0x80 [lpfc] [56048.470493] kthread+0x112/0x130 [56048.470493] ? kthread_flush_work_fn+0x10/0x10 [56048.470494] ret_from_fork+0x1f/0x40 [56048.470494] Kernel panic - not syncing: Hard LOCKUP [56048.470495] CPU: 0 PID: 682 Comm: lpfc_worker_0 Kdump: loaded Tainted: G IOE- - - 4.18.0-240.el8.x86_64 #1 [56048.470496] Hardware name: Dell Inc. PowerEdge R740/0DY2X0, BIOS 2.11.2 004/21/2021 [56048.470496] Call Trace: [56048.470496] [56048.470496] dump_stack+0x5c/0x80 [56048.470497] panic+0xe7/0x2a9 [56048.470497] ? __switch_to_asm+0x51/0x70 [56048.470497] nmi_panic.cold.9+0xc/0xc [56048.470498] watchdog_overflow_callback.cold.7+0x5c/0x70 [56048.470498] __perf_event_overflow+0x52/0xf0 [56048.470499] handle_pmi_common+0x1db/0x270 [56048.470499] ? __set_pte_vaddr+0x32/0x50 [56048.470499] ? __native_set_fixmap+0x24/0x30 [56048.470500] ? ghes_copy_tofrom_phys+0xd3/0x1c0 [56048.470500] ? __ghes_peek_estatus.isra.12+0x49/0xa0 [56048.470500] intel_pmu_handle_irq+0xbf/0x160 [56048.470501] perf_event_nmi_handler+0x2d/0x50 [56048.470501] nmi_handle+0x63/0x110 [56048.470501] default_do_nmi+0x4e/0x100 [56048.470502] do_nmi+0x128/0x190 [56048.470502] end_repeat_nmi+0x16/0x6a [56048.470503] RIP: 0010:native_queued_spin_lock_slowpath+0x5d/0x1d0 [56048.470504] Code: 0f ba 2f 08 0f 92 c0 0f b6 c0 c1 e0 08 89 c2 8b 07 30 e4 09 d0 a9 00 01 ff ff 75 47 85 c0 74 0e 8b 07 84 c0 74 08 f3 90 8b 07 <84> c0 75 f8 b8 01 00 00 00 66 89 07 c3 8b 37 81 fe 00 01 00 00 75 [56048.470504] RSP: 0018:acebc7877ca8 EFLAGS: 0002 [56048.470505] RAX: 0101 RBX: 0246 RCX: 001f [56048.470505] RDX: RSI: RDI: 94dcf5341dc0 [56048.470506] RBP: 94dcf534 R08: 0002 R09: 00029600 [56048.470506] R10: 60d29656a45c R11: 94dcf534fd12 R12: 94dcf5341db0 [56048.470507] R13: 94dcf5341dc0 R14: 94dcc4ae8a00 R15: 0003 [56048.470507] ? native_queued_spin_lock_slowpath+0x5d/0x1d0 [56048.470507] ? native_queued_spin_lock_slowpath+0x5d/0x1d0 [56048.470508] [56048.470508] _raw_spin_lock_irqsave+0x32/0x40 [56048.470509] lpfc_dmp_dbg.part.32+0x28/0x220 [lpfc] [56048.470509] lpfc_cmpl_els_fdisc+0x145/0x460 [lpfc] [56048.470509] lpfc_sli_cancel_jobs+0x92/0xd0 [lpfc] [56048.470510] lpfc_els_flush_cmd+0x43c/0x670 [lpfc] [56048.470510] lpfc_els_flush_all_cmd+0x37/0x60 [lpfc] [56048.470510] lpfc_sli4_async_event_proc+0x956/0x1720 [lpfc] [56048.470511] lpfc_do_work+0x1485/0x1d70 [lpfc] [56048.470511] ? __schedule+0x280/0x700 [56048.470511] ? finish_wait+0x80/0x80 [56048.470512] ? lpfc_unregister_unused_fcf+0x80/0x80 [lpfc] [56048.470512] kthread+0x112/0x130 [56048.470513] ? kthread_flush_work_fn+0x10/0x10 [56048.470513] ret_from_fork+0x1f/0x40 [root@ms-svr3-10-231-131-160 127.0.0.1-2021-11-20-05:14:30]# [root@ms-svr3-10-231-131-160 127.0.0.1-2021-11-20-05:14:30]# cat /etc/redhat-release Red Hat Enterprise Linux release 8.3 (Ootpa) [root@ms-svr3-10-231-131-160 127.0.0.1-2021-11-20-05:14:30]# cat /sys/module/lpfc/version 0:14.0.390.2 [root@ms-svr3-10-231-131-160 127.0.0.1-2021-11-20-05:14:30]# cat /sys/class/scsi_host/host*/modeldesc Emulex LightPulse LPe32002-M2 2-Port 32Gb Fibre Channel Adapter Emulex LightPulse LPe32002-M2 2-Port 32Gb Fibre Channel Adapter [root@ms-svr3-10-231-131-160 127.0.0.1-2021-11-20-05:14:30]# cat /sys/class/scsi_host/host*/fwrev 14.0.390.1, sli-4:2:c 14.0.390.1, sli-4:2:c [root@ms-svr3-10-231-131-160 127.0.0.1-2021-11-20-05:14:30]# cat /sys/class/fc_host/host*/port_name 0x1090faf