[Kernel-packages] [Bug 1996890] Re: linux-modules-nvidia-515-5.17.0-1015-oem couldn't be installed
** Changed in: oem-priority Status: New => Invalid -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to nvidia-graphics-drivers-515 in Ubuntu. https://bugs.launchpad.net/bugs/1996890 Title: linux-modules-nvidia-515-5.17.0-1015-oem couldn't be installed Status in OEM Priority Project: Invalid Status in nvidia-graphics-drivers-515 package in Ubuntu: Invalid Bug description: The linux-modules-nvidia-515-5.17.0-1015-oem is in a wrong dependency. After upgraded to latest kernel 1021-oem, the 1015-oem kernel failed to load the nvidia driver when boot up. rc linux-modules-nvidia-515-5.17.0-1015-oem 5.17.0-1015.16 amd64Linux kernel nvidia modules for version 5.17.0-1015 ii linux-modules-nvidia-515-5.17.0-1021-oem 5.17.0-1021.22 amd64Linux kernel nvidia modules for version 5.17.0-1021 ii linux-modules-nvidia-515-oem-22.04a5.17.0-1021.22 amd64Extra drivers for nvidia-515 for the oem-22.04a flavour ii linux-objects-nvidia-515-5.17.0-1015-oem 5.17.0-1015.16 amd64Linux kernel nvidia modules for version 5.17.0-1015 (objects) ii linux-objects-nvidia-515-5.17.0-1021-oem 5.17.0-1021.22 amd64Linux kernel nvidia modules for version 5.17.0-1021 (objects) ii linux-signatures-nvidia-5.17.0-1015-oem5.17.0-1015.16 amd64Linux kernel signatures for nvidia modules for version 5.17.0-1015-oem ii linux-signatures-nvidia-5.17.0-1021-oem5.17.0-1021.22 amd64Linux kernel signatures for nvidia modules for version 5.17.0-1021-oem ii nvidia-compute-utils-515 515.76+really.515.65.01-0ubuntu0.22.04.2 amd64NVIDIA compute utilities ii nvidia-driver-515 515.76+really.515.65.01-0ubuntu0.22.04.2 amd64NVIDIA driver metapackage ii nvidia-kernel-common-515 515.76+really.515.65.01-0ubuntu0.22.04.2 amd64Shared files used with the kernel module ii nvidia-kernel-source-515 515.76+really.515.65.01-0ubuntu0.22.04.2 amd64NVIDIA kernel source package u@P360-tiny-1:~$ sudo apt install linux-modules-nvidia-515-5.17.0-1015-oem Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: linux-modules-nvidia-515-5.17.0-1015-oem : Depends: nvidia-kernel-common-515 (<= 515.65.01-1) but 515.76+really.515.65.01-0ubuntu0.22.04.2 is to be installed E: Unable to correct problems, you have held broken packages. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1996890/+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 1997946] [NEW] Support soundwire speaker AMP-ALC1318 codec
Public bug reported: Support soundwire speaker AMP-ALC1318 codec. ** Affects: alsa-ucm-conf (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to alsa-ucm-conf in Ubuntu. https://bugs.launchpad.net/bugs/1997946 Title: Support soundwire speaker AMP-ALC1318 codec Status in alsa-ucm-conf package in Ubuntu: New Bug description: Support soundwire speaker AMP-ALC1318 codec. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-ucm-conf/+bug/1997946/+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 1997764] Re: igb driver crashes kernel when receiving jumbo frame UDP packets with all zeros
Since we observed a similar issue I would like to add, that it actually seems like the actual content of the network packet towards the last bytes seems to cause this issue. As stated by Felix it seems to matter that the last 32 or so bytes of the packet contain zeros. One crashdump we observed actually showed one of these zeros on the instruction stack thus it looked to me as the processor tried to execute one of these zeros as a cpu instruction. This can also be seem on dmesg output of Felix's kernel_bug.txt: invalid opcode: [#1] SMP NOPTI -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed-hwe-5.15 in Ubuntu. https://bugs.launchpad.net/bugs/1997764 Title: igb driver crashes kernel when receiving jumbo frame UDP packets with all zeros Status in linux-signed-hwe-5.15 package in Ubuntu: New Bug description: With a high MTU (9000) set on the interface, sending packets containing over ~3000 zero bytes to a network card using the igb driver results in broken packets or in the worst case for some packet sizes even leads to kernel panics or full freeze. So far I observed this for Intel I350 and I210 network cards which use the igb driver. This is easy to reproduce: * set MTU to 9000 * send ping of death: ping -M do -p 00 -s 3016 -> kernel panic or complete freeze of system If the data is not zero, it works fine: ping -M do -p ff -s 3016 Depending on packet length: * < 3000: fine * 3016: panic/freeze * > 3030: packet not complete I also tested this with the following kernel versions: * 5.4.0-131-generic -> OK * 5.8.0-63-generic -> OK * 5.11.0-46-generic -> OK * 5.13.0-52-generic -> broken * 5.15.0-41-generic -> broken * 5.19.5-051905-generic mainline -> broken We noticed that since we have GigE Vision cameras which send the data via UDP with packet sizes up to 9000. When we turned off the light (and hence many bytes in the payload were zero), the packets would not be complete anymore (checked with tcpdump/wireshark) or even lead to kernel panics. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.15.0-53-generic 5.15.0-53.59~20.04.1 ProcVersionSignature: Ubuntu 5.15.0-53.59~20.04.1-generic 5.15.64 Uname: Linux 5.15.0-53-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.25 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Nov 24 13:16:00 2022 SourcePackage: linux-signed-hwe-5.15 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.15/+bug/1997764/+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 1997944] 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 1997944 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-oem-6.0 in Ubuntu. https://bugs.launchpad.net/bugs/1997944 Title: Soundwire support for the Intel RPL Gen platforms Status in HWE Next: New Status in linux package in Ubuntu: Incomplete Status in linux-oem-6.0 package in Ubuntu: Invalid Status in linux source package in Jammy: Won't Fix Status in linux-oem-6.0 source package in Jammy: New Status in linux source package in Lunar: Incomplete Status in linux-oem-6.0 source package in Lunar: Invalid Bug description: TBD. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1997944/+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 1997944] [NEW] Soundwire support for the Intel RPL Gen platforms
Public bug reported: TBD. ** Affects: hwe-next Importance: Undecided Status: New ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Affects: linux-oem-6.0 (Ubuntu) Importance: Undecided Status: Invalid ** Affects: linux (Ubuntu Jammy) Importance: Undecided Status: Won't Fix ** Affects: linux-oem-6.0 (Ubuntu Jammy) Importance: Undecided Status: New ** Affects: linux (Ubuntu Lunar) Importance: Undecided Status: New ** Affects: linux-oem-6.0 (Ubuntu Lunar) Importance: Undecided Status: Invalid ** Tags: oem-priority originate-from-1996028 somerville ** Also affects: linux-oem-6.0 (Ubuntu) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: linux-oem-6.0 (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Lunar) Importance: Undecided Status: New ** Also affects: linux-oem-6.0 (Ubuntu Lunar) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Jammy) Status: New => Won't Fix ** Changed in: linux-oem-6.0 (Ubuntu Lunar) Status: New => Invalid ** Tags added: oem-priority originate-from-1996028 somerville -- 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/1997944 Title: Soundwire support for the Intel RPL Gen platforms Status in HWE Next: New Status in linux package in Ubuntu: New Status in linux-oem-6.0 package in Ubuntu: Invalid Status in linux source package in Jammy: Won't Fix Status in linux-oem-6.0 source package in Jammy: New Status in linux source package in Lunar: New Status in linux-oem-6.0 source package in Lunar: Invalid Bug description: TBD. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1997944/+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 1995046] Re: Realtek 8852c WiFi/BT firmware support
** Tags added: originate-from-1997929 stella -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-firmware in Ubuntu. https://bugs.launchpad.net/bugs/1995046 Title: Realtek 8852c WiFi/BT firmware support Status in HWE Next: New Status in OEM Priority Project: New Status in linux-firmware package in Ubuntu: Fix Released Status in linux-firmware source package in Jammy: Fix Committed Status in linux-firmware source package in Kinetic: Fix Committed Status in linux-firmware source package in Lunar: Fix Released Bug description: [SRU Justification] [Impact] Some OEM design RTK-8852c as WiFi/BT solution on new platform, need to add both FW & config file to get it work with oem-6.0. WiFi: rtw8852c rtw89_8852ce :02:00.0: enabling device ( -> 0003) rtw89_8852ce :02:00.0: Direct firmware load for rtw89/rtw8852c_fw.bin failed with error -2 rtw89_8852ce :02:00.0: failed to request firmware rtw89_8852ce :02:00.0: failed to wait firmware completion rtw89_8852ce :02:00.0: failed to setup chip information rtw89_8852ce: probe of :02:00.0 failed with error -22 BT: rtl8852cu Bluetooth: hci0: RTL: loading rtl_bt/rtl8852cu_fw.bin Bluetooth: hci0: RTL: firmware file rtl_bt/rtl8852cu_fw.bin not found [Fix] rtw89/rtw8852c_fw.bin and rtl_bt/rtl8852cu_fw.bin are required. Kinetic has already 5 commits out of 8. [Test Case] The driver will prompt for missed firmware blobs for a given platform. [Where problems could occur] New device to be supported for Jammy oem-6.0. May cause system stability issues or power consumption performance. [Other Info] This device is supported since v5.19, so only Jammy (for oem-6.0) and Kinetic are nominated for fix. == original bug report == Some OEM design RTK-8852c as WiFi/BT solution on new platform, need to add both FW & config file to get it work with oem-6.0. WiFi: rtw8852c [ 2.628042] rtw89_8852ce :02:00.0: enabling device ( -> 0003) [ 2.628647] rtw89_8852ce :02:00.0: Direct firmware load for rtw89/rtw8852c_fw.bin failed with error -2 [ 2.628663] rtw89_8852ce :02:00.0: failed to request firmware [ 2.644819] rtw89_8852ce :02:00.0: failed to wait firmware completion [ 2.644843] rtw89_8852ce :02:00.0: failed to setup chip information [ 2.649823] rtw89_8852ce: probe of :02:00.0 failed with error -22 https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux- firmware.git/commit/?id=d2aac63b8381c0633de00476a7f3d8f436ea4bc5 BT: rtl8852cu [ 2.476240] Bluetooth: hci0: RTL: loading rtl_bt/rtl8852cu_fw.bin [ 2.476441] Bluetooth: hci0: RTL: firmware file rtl_bt/rtl8852cu_fw.bin not found https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux- firmware.git/commit/?id=8a2d811764e7fcc9e2862549f91487770b70563b https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux- firmware.git/commit/?id=cfbd6681696ba4b5eed279f28983d6a87cd6fd90 To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1995046/+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 1996678] Re: containerd sporadic timeouts
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: containerd (Ubuntu Focal) 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/1996678 Title: containerd sporadic timeouts Status in containerd package in Ubuntu: Confirmed Status in linux package in Ubuntu: Invalid Status in containerd source package in Focal: Confirmed Status in linux source package in Focal: In Progress Bug description: This morning I routinely upgraded security upgrades on number of machines. Containerd has upgraded from `1.5.9-0ubuntu1~20.04.4` for me `1.5.9-0ubuntu1~20.04.5`. What happened next: at some random time on machines with new containerd something happens with containerd tasks and/or cgroups. This is how it's seen in syslog: containerd[710]: time="2022-11-16T03:21:21.004153517Z" level=error msg="get state for 2f5a8376b476809b1696b140ca87f91422113bb16b27a8174437cc63b48e259a" error="context deadline exceeded: unknown" And some ctr commands: # ctr --namespace k8s.io task ls|grep 2f5a8376b476809b1696b140ca87f91422113bb16b27a8174437cc63b48e259a 2f5a8376b476809b1696b140ca87f91422113bb16b27a8174437cc63b48e259a0 UNKNOWN See that the status of the task is UNKNOWN (!!!) # ctr --namespace k8s.io container ls|grep 2f5a8376b476809b1696b140ca87f91422113bb16b27a8174437cc63b48e259a 2f5a8376b476809b1696b140ca87f91422113bb16b27a8174437cc63b48e259a k8s.gcr.io/pause:3.5 io.containerd.runc.v2 Cgroups: ├─kubepods-besteffort-pod3fdc0061_bbf6_47d1_97f5_b1f271b46e23.slice │ ├─cri-containerd-5f78e0cb957de97fd8465cc42c842bdd764d981ca7a903a2515bbc6bb06796a9.scope … │ │ └─2677 /csi-node-driver-registrar --v=0 --csi-address=/csi/csi.sock --k… │ ├─cri-containerd-af070f16c1f0ff22eb16661e787e85db3810727909abd23d69a6a43578c1dced.scope … │ │ └─3264 /usr/local/bin/cephcsi --type=liveness --endpoint=unix:///csi/cs… │ ├─cri-containerd-4e063ef0c8f768dbf34cf7a179bca5cc98a04fa7e00b29d20c17d3031d409f86.scope … │ │ └─2960 /usr/local/bin/cephcsi --nodeid=nas-decent-bobcat.dev-k8s-1.hq.w… │ └─cri-containerd-2f5a8376b476809b1696b140ca87f91422113bb16b27a8174437cc63b48e259a.scope … │ └─2414 /pause # ps auxf|grep 2414 -B 2 root2279 0.1 0.0 114100 4956 ?Sl Nov15 0:42 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id 2f5a8376b476809b1696b140ca87f91422113bb16b27a8174437cc63b48e259a -address /run/containerd/containerd.sock 65535 2414 0.0 0.0964 4 ?Ss Nov15 0:00 \_ /pause It happens not immediately - but after some random time. Sometimes it's several minutes, sometimes it's around an hour. But nonetheless - all machines with the new package get into this weird state. As long as I revert package - it all returns to run as expected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/containerd/+bug/1996678/+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 1997914] 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 1997914 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/1997914 Title: intel/sof firmware is undeclared Status in linux package in Ubuntu: Incomplete Bug description: intel/sof firmware is undeclared by the modules that load it To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1997914/+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 1997914] [NEW] intel/sof firmware is undeclared
Public bug reported: intel/sof firmware is undeclared by the modules that load it ** 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/1997914 Title: intel/sof firmware is undeclared Status in linux package in Ubuntu: New Bug description: intel/sof firmware is undeclared by the modules that load it To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1997914/+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 1997910] 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 1997910 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/1997910 Title: Undeclared btqca and btusb firmware Status in linux package in Ubuntu: Incomplete Bug description: Undeclared btusb firmware btusb.ko can request snprintf(fwname, sizeof(fwname), "qca/rampatch_usb_%08x.bin", ver_rom); but doesn't declare it as MODULES_FIRMWARE. btqca can request lots of qca/ things To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1997910/+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 1997910] [NEW] Undeclared btqca and btusb firmware
Public bug reported: Undeclared btusb firmware btusb.ko can request snprintf(fwname, sizeof(fwname), "qca/rampatch_usb_%08x.bin", ver_rom); but doesn't declare it as MODULES_FIRMWARE. btqca can request lots of qca/ things ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete ** Summary changed: - Undeclared btusb firmware + Undeclared btqca and btusb firmware ** Description changed: Undeclared btusb firmware btusb.ko can request snprintf(fwname, sizeof(fwname), "qca/rampatch_usb_%08x.bin", ver_rom); but doesn't declare it as MODULES_FIRMWARE. + + btqca can request lots of qca/ things -- 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/1997910 Title: Undeclared btqca and btusb firmware Status in linux package in Ubuntu: Incomplete Bug description: Undeclared btusb firmware btusb.ko can request snprintf(fwname, sizeof(fwname), "qca/rampatch_usb_%08x.bin", ver_rom); but doesn't declare it as MODULES_FIRMWARE. btqca can request lots of qca/ things To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1997910/+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 1997908] [NEW] Wi-Fi 6E does not work in Canada with Intel AX210
Public bug reported: Intel has been adding support for Wi-Fi 6E (6GHz band) to additional countries as they get regulatory approval. With the base install of Ubuntu 22.10, I do not have 6GHz support while in Canada, and have confirmed with 'iw reg get'. Intel has released an updated pnvm file to support more countries: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/iwlwifi-ty-a0-gf-a0.pnvm?id=20d9516de4cdc041e2aa83009e5b0464b1c3ed81 After copying the latest iwlwifi-ty-a0-gf-a0-72.ucode and iwlwifi- ty-a0-gf-a0.pnvm from git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux- firmware.git and rebooting I now have full support: $ iw reg get [...] (5945 - 5965 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, PASSIVE-SCAN (5965 - 5985 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, PASSIVE-SCAN (5985 - 6005 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, PASSIVE-SCAN (6005 - 6025 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, PASSIVE-SCAN (6025 - 6045 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, PASSIVE-SCAN (6045 - 6065 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, PASSIVE-SCAN (6065 - 6085 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, PASSIVE-SCAN (6085 - 6105 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, PASSIVE-SCAN (6105 - 6125 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, PASSIVE-SCAN (6125 - 6145 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, PASSIVE-SCAN (6145 - 6165 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, PASSIVE-SCAN (6165 - 6185 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, PASSIVE-SCAN (6185 - 6205 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, PASSIVE-SCAN (6205 - 6225 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, PASSIVE-SCAN (6225 - 6245 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, PASSIVE-SCAN (6245 - 6265 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, PASSIVE-SCAN (6265 - 6285 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, PASSIVE-SCAN (6285 - 6305 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, PASSIVE-SCAN (6305 - 6325 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, PASSIVE-SCAN (6325 - 6345 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, PASSIVE-SCAN (6345 - 6365 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, PASSIVE-SCAN Can we update the linux-firmware package for kinetic to include the latest pnmv and core 72 firmware? ** Affects: linux-firmware (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-firmware in Ubuntu. https://bugs.launchpad.net/bugs/1997908 Title: Wi-Fi 6E does not work in Canada with Intel AX210 Status in linux-firmware package in Ubuntu: New Bug description: Intel has been adding support for Wi-Fi 6E (6GHz band) to additional countries as they get regulatory approval. With the base install of Ubuntu 22.10, I do not have 6GHz support while in Canada, and have confirmed with 'iw reg get'. Intel has released an updated pnvm file to support more countries: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/iwlwifi-ty-a0-gf-a0.pnvm?id=20d9516de4cdc041e2aa83009e5b0464b1c3ed81 After copying the latest iwlwifi-ty-a0-gf-a0-72.ucode and iwlwifi- ty-a0-gf-a0.pnvm from git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux- firmware.git and rebooting I now have full support: $ iw reg get [...] (5945 - 5965 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, PASSIVE-SCAN (5965 - 5985 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, PASSIVE-SCAN (5985 - 6005 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, PASSIVE-SCAN (6005 - 6025 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, PASSIVE-SCAN (6025 - 6045 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, PASSIVE-SCAN (6045 - 6065 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, PASSIVE-SCAN (6065 - 6085 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, PASSIVE-SCAN (6085 - 6105 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, PASSIVE-SCAN (6105 - 6125 @ 1180), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, PASSIVE-SCAN (6125 - 6145 @ 1180), (6, 22),
[Kernel-packages] [Bug 1996678] Re: containerd sporadic timeouts
Right, 1 day running patched kernel proven it has fixed the issue. Given there is a proper report in github - I will probably revert to some older official kernel version. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1996678 Title: containerd sporadic timeouts Status in containerd package in Ubuntu: Confirmed Status in linux package in Ubuntu: Invalid Status in containerd source package in Focal: New Status in linux source package in Focal: In Progress Bug description: This morning I routinely upgraded security upgrades on number of machines. Containerd has upgraded from `1.5.9-0ubuntu1~20.04.4` for me `1.5.9-0ubuntu1~20.04.5`. What happened next: at some random time on machines with new containerd something happens with containerd tasks and/or cgroups. This is how it's seen in syslog: containerd[710]: time="2022-11-16T03:21:21.004153517Z" level=error msg="get state for 2f5a8376b476809b1696b140ca87f91422113bb16b27a8174437cc63b48e259a" error="context deadline exceeded: unknown" And some ctr commands: # ctr --namespace k8s.io task ls|grep 2f5a8376b476809b1696b140ca87f91422113bb16b27a8174437cc63b48e259a 2f5a8376b476809b1696b140ca87f91422113bb16b27a8174437cc63b48e259a0 UNKNOWN See that the status of the task is UNKNOWN (!!!) # ctr --namespace k8s.io container ls|grep 2f5a8376b476809b1696b140ca87f91422113bb16b27a8174437cc63b48e259a 2f5a8376b476809b1696b140ca87f91422113bb16b27a8174437cc63b48e259a k8s.gcr.io/pause:3.5 io.containerd.runc.v2 Cgroups: ├─kubepods-besteffort-pod3fdc0061_bbf6_47d1_97f5_b1f271b46e23.slice │ ├─cri-containerd-5f78e0cb957de97fd8465cc42c842bdd764d981ca7a903a2515bbc6bb06796a9.scope … │ │ └─2677 /csi-node-driver-registrar --v=0 --csi-address=/csi/csi.sock --k… │ ├─cri-containerd-af070f16c1f0ff22eb16661e787e85db3810727909abd23d69a6a43578c1dced.scope … │ │ └─3264 /usr/local/bin/cephcsi --type=liveness --endpoint=unix:///csi/cs… │ ├─cri-containerd-4e063ef0c8f768dbf34cf7a179bca5cc98a04fa7e00b29d20c17d3031d409f86.scope … │ │ └─2960 /usr/local/bin/cephcsi --nodeid=nas-decent-bobcat.dev-k8s-1.hq.w… │ └─cri-containerd-2f5a8376b476809b1696b140ca87f91422113bb16b27a8174437cc63b48e259a.scope … │ └─2414 /pause # ps auxf|grep 2414 -B 2 root2279 0.1 0.0 114100 4956 ?Sl Nov15 0:42 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id 2f5a8376b476809b1696b140ca87f91422113bb16b27a8174437cc63b48e259a -address /run/containerd/containerd.sock 65535 2414 0.0 0.0964 4 ?Ss Nov15 0:00 \_ /pause It happens not immediately - but after some random time. Sometimes it's several minutes, sometimes it's around an hour. But nonetheless - all machines with the new package get into this weird state. As long as I revert package - it all returns to run as expected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/containerd/+bug/1996678/+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 1996678] Re: containerd sporadic timeouts
Hi Hans, Thanks for the pointer to the synthetic reproducer! It provided accurate and consistent results considering the kernel versions reported (not) to exhibit the issue. The Azure test kernel with the 3 patches [1] to address that shows the same (good) results as the Azure kernel prior to the regression being introduced. P.S.: the issue isn't strictly having that patch in, as it's included in later kernel versions w/out this issue (eg, 5.15), but having that patch in while not having these other patches in as well (as, eg, 5.15). [1] https://lists.ubuntu.com/archives/kernel- team/2022-November/135069.html ... Test Results from 4x VMs on Azure (2x 4vCPU/16G and 2x 8vCPU/32G) Test Steps follow below; essentially, run the for-loop with curl 10x times, and count how many times it doesn't finish / is stuck. (i.e., epoll wait didn't return/finish). 1) original/"good" kernel: 0% error rate -- 5.4.0-1094-azure #100-Ubuntu SMP Mon Oct 17 03:14:36 UTC 2022 VM1: 0/10 VM2: 0/10 VM3: 0/10 VM4: 0/10 2) regression/"bad" kernel: 60%-80% error rate -- 5.4.0-1095-azure #101-Ubuntu SMP Thu Oct 20 15:50:47 UTC 2022 VM1: 8/10 VM2: 7/10 VM3: 7/10 VM4: 6/10 3) candidate/"test" kernel: 0% error rate -- 5.4.0-1098-azure #104-Ubuntu SMP Wed Nov 23 21:19:57 UTC 2022 VM1: 0/10 VM2: 0/10 VM3: 0/10 VM4: 0/10 ... Test Steps/Criteria on Focal: Install go 1.19: $ sudo snap install --channel=1.19/stable --classic go Create test programs: $ cat] ep_poll+0x3bb/0x410 /proc/33267/task/33287/stack:[<0>] do_epoll_wait+0xb8/0xd0 /proc/33267/task/33287/stack:[<0>] __x64_sys_epoll_pwait+0x4c/0xa0 /proc/33267/task/33287/stack:[<0>] do_syscall_64+0x5e/0x200 /proc/33267/task/33287/stack:[<0>] entry_SYSCALL_64_after_hwframe+0x5c/0xc1 azureuser@ktest-3:~$ sudo grep -l epoll /proc/$(pidof go)/task/*/stack | xargs sudo grep -H ^ /proc/1193/task/1193/stack:[<0>] ep_poll+0x3bb/0x410 /proc/1193/task/1193/stack:[<0>] do_epoll_wait+0xb8/0xd0 /proc/1193/task/1193/stack:[<0>] __x64_sys_epoll_pwait+0x4c/0xa0 /proc/1193/task/1193/stack:[<0>] do_syscall_64+0x5e/0x200 /proc/1193/task/1193/stack:[<0>] entry_SYSCALL_64_after_hwframe+0x5c/0xc1 azureuser@ktest-3:~$ sudo grep -l epoll /proc/$(pidof go)/task/*/stack | xargs sudo grep -H ^ /proc/1173/task/1193/stack:[<0>] ep_poll+0x3bb/0x410 /proc/1173/task/1193/stack:[<0>] do_epoll_wait+0xb8/0xd0 /proc/1173/task/1193/stack:[<0>] __x64_sys_epoll_pwait+0x4c/0xa0 /proc/1173/task/1193/stack:[<0>] do_syscall_64+0x5e/0x200 /proc/1173/task/1193/stack:[<0>] entry_SYSCALL_64_after_hwframe+0x5c/0xc1 -- 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/1996678 Title: containerd sporadic timeouts Status in containerd package in Ubuntu: Confirmed Status in linux package in Ubuntu: Invalid Status in containerd source package in Focal: New Status in linux source package in Focal: In Progress Bug description: This morning I routinely upgraded security upgrades on number of machines. Containerd has upgraded from `1.5.9-0ubuntu1~20.04.4` for me `1.5.9-0ubuntu1~20.04.5`. What happened next: at some random time on machines with new containerd something happens with containerd tasks and/or cgroups. This is how it's seen in syslog: containerd[710]: time="2022-11-16T03:21:21.004153517Z" level=error msg="get state for
[Kernel-packages] [Bug 1997905] 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 1997905 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/1997905 Title: nfs mount in fstab on vers. 5.15.0.53 doesn't work Status in linux package in Ubuntu: Incomplete Bug description: I added the same mounting commands in fstab as I used for Kernel v5.15.0.52. However the mounting will not complete. I can't get to the login window (it hangs on the Linux-Mint-Logo.. nfs-common is installed on the system. I used the syntax: :/ nfs _netdev defaults 0 0 Thanks PS. I report this under Kernel v 5.15.0.52 since I can't login into v 5.15.0.53 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1997905/+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 1997905] [NEW] nfs mount in fstab on vers. 5.15.0.53 doesn't work
Public bug reported: I added the same mounting commands in fstab as I used for Kernel v5.15.0.52. However the mounting will not complete. I can't get to the login window (it hangs on the Linux-Mint-Logo.. nfs-common is installed on the system. I used the syntax: :/ nfs _netdev defaults 0 0 Thanks PS. I report this under Kernel v 5.15.0.52 since I can't login into v 5.15.0.53 ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Attachment added: "just lspci-vnvn.log (can upload only 1 file)" https://bugs.launchpad.net/bugs/1997905/+attachment/5632724/+files/lspci-vnvn.log -- 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/1997905 Title: nfs mount in fstab on vers. 5.15.0.53 doesn't work Status in linux package in Ubuntu: New Bug description: I added the same mounting commands in fstab as I used for Kernel v5.15.0.52. However the mounting will not complete. I can't get to the login window (it hangs on the Linux-Mint-Logo.. nfs-common is installed on the system. I used the syntax: :/ nfs _netdev defaults 0 0 Thanks PS. I report this under Kernel v 5.15.0.52 since I can't login into v 5.15.0.53 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1997905/+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 1993120] Re: armhf kernel compiled with gcc-12 fails to boot on pi 3/2
It's a raspi kernel only issue. The downstream dwc_otg driver is not gcc-12 stack-protector safe. ** Changed in: linux-raspi (Ubuntu Kinetic) Status: Invalid => Fix Committed ** Changed in: linux (Ubuntu Kinetic) Status: Fix Committed => Invalid ** Changed in: gcc-12 (Ubuntu Kinetic) Status: New => Invalid ** Changed in: gcc-12 (Ubuntu) Status: Incomplete => Invalid ** Changed in: linux-raspi (Ubuntu Kinetic) Status: Fix Committed => 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/1993120 Title: armhf kernel compiled with gcc-12 fails to boot on pi 3/2 Status in gcc-12 package in Ubuntu: Invalid Status in linux package in Ubuntu: Invalid Status in linux-raspi package in Ubuntu: Fix Released Status in gcc-12 source package in Kinetic: Invalid Status in linux source package in Kinetic: Invalid Status in linux-raspi source package in Kinetic: Fix Released Bug description: Kinetic 5.19 kernels compiled with gcc-12 for armhf don't boot or hang on Pi 3 and 2. Seems to work fine on Pi 4. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gcc-12/+bug/1993120/+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 1997764] Re: igb driver crashes kernel when receiving jumbo frame UDP packets with all zeros
** Description changed: With a high MTU (9000) set on the interface, sending packets containing over ~3000 zero bytes to a network card using the igb driver results in broken packets or in the worst case for some packet sizes even leads to kernel panics or full freeze. So far I observed this for Intel I350 and I210 network cards which use the igb driver. This is easy to reproduce: * set MTU to 9000 * send ping of death: ping -M do -p 00 -s 3016 -> kernel panic or complete freeze of system If the data is not zero, it works fine: ping -M do -p ff -s 3016 Depending on packet length: * < 3000: fine * 3016: panic/freeze * > 3030: packet not complete I also tested this with the following kernel versions: - * 5.4.0-131-generic + * 5.4.0-131-generic -> OK * 5.8.0-63-generic -> OK * 5.11.0-46-generic -> OK * 5.13.0-52-generic -> broken * 5.15.0-41-generic -> broken * 5.19.5-051905-generic mainline -> broken We noticed that since we have GigE Vision cameras which send the data via UDP with packet sizes up to 9000. When we turned off the light (and hence many bytes in the payload were zero), the packets would not be complete anymore (checked with tcpdump/wireshark) or even lead to kernel panics. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.15.0-53-generic 5.15.0-53.59~20.04.1 ProcVersionSignature: Ubuntu 5.15.0-53.59~20.04.1-generic 5.15.64 Uname: Linux 5.15.0-53-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.25 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Nov 24 13:16:00 2022 SourcePackage: linux-signed-hwe-5.15 UpgradeStatus: No upgrade log present (probably fresh install) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed-hwe-5.15 in Ubuntu. https://bugs.launchpad.net/bugs/1997764 Title: igb driver crashes kernel when receiving jumbo frame UDP packets with all zeros Status in linux-signed-hwe-5.15 package in Ubuntu: New Bug description: With a high MTU (9000) set on the interface, sending packets containing over ~3000 zero bytes to a network card using the igb driver results in broken packets or in the worst case for some packet sizes even leads to kernel panics or full freeze. So far I observed this for Intel I350 and I210 network cards which use the igb driver. This is easy to reproduce: * set MTU to 9000 * send ping of death: ping -M do -p 00 -s 3016 -> kernel panic or complete freeze of system If the data is not zero, it works fine: ping -M do -p ff -s 3016 Depending on packet length: * < 3000: fine * 3016: panic/freeze * > 3030: packet not complete I also tested this with the following kernel versions: * 5.4.0-131-generic -> OK * 5.8.0-63-generic -> OK * 5.11.0-46-generic -> OK * 5.13.0-52-generic -> broken * 5.15.0-41-generic -> broken * 5.19.5-051905-generic mainline -> broken We noticed that since we have GigE Vision cameras which send the data via UDP with packet sizes up to 9000. When we turned off the light (and hence many bytes in the payload were zero), the packets would not be complete anymore (checked with tcpdump/wireshark) or even lead to kernel panics. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.15.0-53-generic 5.15.0-53.59~20.04.1 ProcVersionSignature: Ubuntu 5.15.0-53.59~20.04.1-generic 5.15.64 Uname: Linux 5.15.0-53-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.25 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Nov 24 13:16:00 2022 SourcePackage: linux-signed-hwe-5.15 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.15/+bug/1997764/+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 1996730] Re: Missing firmware in kernel snap
** Changed in: linux (Ubuntu) Status: Triaged => 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/1996730 Title: Missing firmware in kernel snap Status in linux package in Ubuntu: Fix Released Bug description: alsa-topology-conf is part of the desktop image. It installs /lib/firmware/skl_hda_dsp_generic-tplg.bin this firmware file is missing from kernel snaps To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1996730/+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 1997899] [NEW] By moving the windows from every application after a hour its getting slow and hangs for 10 / 15 seconds.
Public bug reported: I tried a lot, but am not so experienced. I hope you can help me. Fur fuhrter information please write me and tell me how. The screen is a LCD 55 inch. Unfder windows I dont have any problems. With kind regards from Holland, Hans.. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: nvidia-driver-515 515.76+really.515.65.01-0ubuntu0.22.04.2 ProcVersionSignature: Ubuntu 5.15.0-54.60-generic 5.15.74 Uname: Linux 5.15.0-54-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.2 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Thu Nov 24 19:28:54 2022 InstallationDate: Installed on 2022-04-29 (209 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=nl_NL.UTF-8 SHELL=/bin/bash SourcePackage: nvidia-graphics-drivers-515 UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: nvidia-graphics-drivers-515 (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 nvidia-graphics-drivers-515 in Ubuntu. https://bugs.launchpad.net/bugs/1997899 Title: By moving the windows from every application after a hour its getting slow and hangs for 10 / 15 seconds. Status in nvidia-graphics-drivers-515 package in Ubuntu: New Bug description: I tried a lot, but am not so experienced. I hope you can help me. Fur fuhrter information please write me and tell me how. The screen is a LCD 55 inch. Unfder windows I dont have any problems. With kind regards from Holland, Hans.. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: nvidia-driver-515 515.76+really.515.65.01-0ubuntu0.22.04.2 ProcVersionSignature: Ubuntu 5.15.0-54.60-generic 5.15.74 Uname: Linux 5.15.0-54-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.2 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Thu Nov 24 19:28:54 2022 InstallationDate: Installed on 2022-04-29 (209 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=nl_NL.UTF-8 SHELL=/bin/bash SourcePackage: nvidia-graphics-drivers-515 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-515/+bug/1997899/+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 1996740] Re: 5.15.0-53-generic no longer boots
Notice that the fix is available at ppa:canonical-kernel-team/ppa2 as linux 5.15.0-56. -- 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/1996740 Title: 5.15.0-53-generic no longer boots Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Committed Bug description: == SRU Justification == [Impact] "UBUNTU: SAUCE: Revert "drm/amd/display: Add helper for blanking all dp displays" caused AMD Navi10 GFX to panic at boot. [Fix] Backport the revised version of "drm/amd/display: Add helper for blanking all dp displays". [Test] Users confirmed the issue went away with this fix. We also verified the original issue we fixed didn't reappear. [Where problems could occur] We didn't test all the combination of dce110/dcn10/dcn30/dcn31, so many cases are untested, hence the potential risk is there. == Original Bug Report == Running Ubuntu 22.04.1 Jammy. After kernel update from 5.15.0-52-generic to 5.15.0-53-generic the system no longer fully boots. After the normal splash screen the screen goes black and the computer is not reachable on the network. Changing to another TTY does not work. New kernel version: 5.15.0-53.59 I will attach the output of journalctl -b -1, please let me know what other info you need. --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: johan 2549 F pulseaudio /dev/snd/controlC0: johan 2549 F pulseaudio CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 22.04 InstallationDate: Installed on 2020-12-01 (714 days ago) InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022) IwConfig: lono wireless extensions. enp37s0 no wireless extensions. wgnfs no wireless extensions. MachineType: Micro-Star International Co., Ltd. MS-7C52 Package: linux (not installed) ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-52-generic root=UUID=b2063474-5791-4f32-aa6d-88a478ae3120 ro quiet splash vt.handoff=7 ProcVersionSignature: Ubuntu 5.15.0-52.58-generic 5.15.60 RelatedPackageVersions: linux-restricted-modules-5.15.0-52-generic N/A linux-backports-modules-5.15.0-52-generic N/A linux-firmware 20220329.git681281e4-0ubuntu3.6 RfKill: 0: hci0: Bluetooth Soft blocked: no Hard blocked: no Tags: jammy wayland-session Uname: Linux 5.15.0-52-generic x86_64 UpgradeStatus: Upgraded to jammy on 2022-11-16 (0 days ago) UserGroups: adm cdrom dialout dip kvm libvirt lpadmin lxd plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 07/23/2022 dmi.bios.release: 5.17 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: 3.G0 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: B450M-A PRO MAX (MS-7C52) dmi.board.vendor: Micro-Star International Co., Ltd. dmi.board.version: 1.0 dmi.chassis.asset.tag: To be filled by O.E.M. dmi.chassis.type: 3 dmi.chassis.vendor: Micro-Star International Co., Ltd. dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvr3.G0:bd07/23/2022:br5.17:svnMicro-StarInternationalCo.,Ltd.:pnMS-7C52:pvr1.0:rvnMicro-StarInternationalCo.,Ltd.:rnB450M-APROMAX(MS-7C52):rvr1.0:cvnMicro-StarInternationalCo.,Ltd.:ct3:cvr1.0:skuTobefilledbyO.E.M.: dmi.product.family: To be filled by O.E.M. dmi.product.name: MS-7C52 dmi.product.sku: To be filled by O.E.M. dmi.product.version: 1.0 dmi.sys.vendor: Micro-Star International Co., Ltd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1996740/+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 1997764] Re: igb driver crashes kernel when receiving jumbo frame UDP packets with all zeros
** Description changed: With a high MTU (9000) set on the interface, sending packets containing over ~3000 zero bytes to a network card using the igb driver results in broken packets or in the worst case for some packet sizes even leads to kernel panics or full freeze. So far I observed this for Intel I350 and I210 network cards which use the igb driver. This is easy to reproduce: * set MTU to 9000 * send ping of death: ping -M do -p 00 -s 3016 -> kernel panic or complete freeze of system If the data is not zero, it works fine: ping -M do -p ff -s 3016 Depending on packet length: * < 3000: fine * 3016: panic/freeze * > 3030: packet not complete I also tested this with the following kernel versions: + * 5.4.0-131-generic * 5.8.0-63-generic -> OK * 5.11.0-46-generic -> OK * 5.13.0-52-generic -> broken * 5.15.0-41-generic -> broken * 5.19.5-051905-generic mainline -> broken We noticed that since we have GigE Vision cameras which send the data via UDP with packet sizes up to 9000. When we turned off the light (and hence many bytes in the payload were zero), the packets would not be complete anymore (checked with tcpdump/wireshark) or even lead to kernel panics. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.15.0-53-generic 5.15.0-53.59~20.04.1 ProcVersionSignature: Ubuntu 5.15.0-53.59~20.04.1-generic 5.15.64 Uname: Linux 5.15.0-53-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.25 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Nov 24 13:16:00 2022 SourcePackage: linux-signed-hwe-5.15 UpgradeStatus: No upgrade log present (probably fresh install) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed-hwe-5.15 in Ubuntu. https://bugs.launchpad.net/bugs/1997764 Title: igb driver crashes kernel when receiving jumbo frame UDP packets with all zeros Status in linux-signed-hwe-5.15 package in Ubuntu: New Bug description: With a high MTU (9000) set on the interface, sending packets containing over ~3000 zero bytes to a network card using the igb driver results in broken packets or in the worst case for some packet sizes even leads to kernel panics or full freeze. So far I observed this for Intel I350 and I210 network cards which use the igb driver. This is easy to reproduce: * set MTU to 9000 * send ping of death: ping -M do -p 00 -s 3016 -> kernel panic or complete freeze of system If the data is not zero, it works fine: ping -M do -p ff -s 3016 Depending on packet length: * < 3000: fine * 3016: panic/freeze * > 3030: packet not complete I also tested this with the following kernel versions: * 5.4.0-131-generic * 5.8.0-63-generic -> OK * 5.11.0-46-generic -> OK * 5.13.0-52-generic -> broken * 5.15.0-41-generic -> broken * 5.19.5-051905-generic mainline -> broken We noticed that since we have GigE Vision cameras which send the data via UDP with packet sizes up to 9000. When we turned off the light (and hence many bytes in the payload were zero), the packets would not be complete anymore (checked with tcpdump/wireshark) or even lead to kernel panics. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.15.0-53-generic 5.15.0-53.59~20.04.1 ProcVersionSignature: Ubuntu 5.15.0-53.59~20.04.1-generic 5.15.64 Uname: Linux 5.15.0-53-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.25 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Nov 24 13:16:00 2022 SourcePackage: linux-signed-hwe-5.15 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.15/+bug/1997764/+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 1997764] Re: igb driver crashes kernel when receiving jumbo frame UDP packets with all zeros
** Description changed: With a high MTU (9000) set on the interface, sending packets containing over ~3000 zero bytes to a network card using the igb driver results in broken packets or in the worst case for some packet sizes even leads to kernel panics or full freeze. So far I observed this for Intel I350 and I210 network cards which use the igb driver. This is easy to reproduce: * set MTU to 9000 - * send ping of death: ping -M do -p 00 3016 + * send ping of death: ping -M do -p 00 -s 3016 -> kernel panic or complete freeze of system If the data is not zero, it works fine: ping -M do -p ff 3016 Depending on packet length: * < 3000: fine * 3016: panic/freeze * > 3030: packet not complete I also tested this with the following kernel versions: * 5.8.0-63-generic -> OK * 5.11.0-46-generic -> OK * 5.13.0-52-generic -> broken * 5.15.0-41-generic -> broken * 5.19.5-051905-generic mainline -> broken We noticed that since we have GigE Vision cameras which send the data via UDP with packet sizes up to 9000. When we turned off the light (and hence many bytes in the payload were zero), the packets would not be complete anymore (checked with tcpdump/wireshark) or even lead to kernel panics. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.15.0-53-generic 5.15.0-53.59~20.04.1 ProcVersionSignature: Ubuntu 5.15.0-53.59~20.04.1-generic 5.15.64 Uname: Linux 5.15.0-53-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.25 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Nov 24 13:16:00 2022 SourcePackage: linux-signed-hwe-5.15 UpgradeStatus: No upgrade log present (probably fresh install) ** Description changed: With a high MTU (9000) set on the interface, sending packets containing over ~3000 zero bytes to a network card using the igb driver results in broken packets or in the worst case for some packet sizes even leads to kernel panics or full freeze. So far I observed this for Intel I350 and I210 network cards which use the igb driver. This is easy to reproduce: * set MTU to 9000 * send ping of death: ping -M do -p 00 -s 3016 -> kernel panic or complete freeze of system If the data is not zero, it works fine: - ping -M do -p ff 3016 + ping -M do -p ff -s 3016 Depending on packet length: * < 3000: fine * 3016: panic/freeze * > 3030: packet not complete I also tested this with the following kernel versions: * 5.8.0-63-generic -> OK * 5.11.0-46-generic -> OK * 5.13.0-52-generic -> broken * 5.15.0-41-generic -> broken * 5.19.5-051905-generic mainline -> broken We noticed that since we have GigE Vision cameras which send the data via UDP with packet sizes up to 9000. When we turned off the light (and hence many bytes in the payload were zero), the packets would not be complete anymore (checked with tcpdump/wireshark) or even lead to kernel panics. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.15.0-53-generic 5.15.0-53.59~20.04.1 ProcVersionSignature: Ubuntu 5.15.0-53.59~20.04.1-generic 5.15.64 Uname: Linux 5.15.0-53-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.25 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Nov 24 13:16:00 2022 SourcePackage: linux-signed-hwe-5.15 UpgradeStatus: No upgrade log present (probably fresh install) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed-hwe-5.15 in Ubuntu. https://bugs.launchpad.net/bugs/1997764 Title: igb driver crashes kernel when receiving jumbo frame UDP packets with all zeros Status in linux-signed-hwe-5.15 package in Ubuntu: New Bug description: With a high MTU (9000) set on the interface, sending packets containing over ~3000 zero bytes to a network card using the igb driver results in broken packets or in the worst case for some packet sizes even leads to kernel panics or full freeze. So far I observed this for Intel I350 and I210 network cards which use the igb driver. This is easy to reproduce: * set MTU to 9000 * send ping of death: ping -M do -p 00 -s 3016 -> kernel panic or complete freeze of system If the data is not zero, it works fine: ping -M do -p ff -s 3016 Depending on packet length: * < 3000: fine * 3016: panic/freeze * > 3030: packet not complete I also tested this with the following kernel versions: * 5.8.0-63-generic -> OK * 5.11.0-46-generic -> OK * 5.13.0-52-generic -> broken * 5.15.0-41-generic -> broken * 5.19.5-051905-generic mainline -> broken We noticed that since we have GigE Vision cameras which send the data via UDP with packet sizes up to 9000. When we turned off the light (and hence many bytes in the payload were zero), the packets would not be complete anymore (checked with tcpdump/wireshark) or even lead to kernel panics. ProblemType: Bug
[Kernel-packages] [Bug 1516025] Re: Realtek ALC3661 Alienware14 / Soundoutput / Jack
Launchpad has imported 136 comments from the remote bug at
https://bugzilla.kernel.org/show_bug.cgi?id=107851.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
On 2015-11-14T13:36:22+00:00 imranmohd72 wrote:
Missing sub-woofer pin and headset mic
More details here
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1302090
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1516025/comments/7
On 2015-11-14T13:40:01+00:00 imranmohd72 wrote:
you have not set node 0x1a to speaker in
/sys/class/sound/hwC1D0/user_pin_configs:
/sys/class/sound/hwC1D0/init_pin_configs:
0x12 0x99a30140
0x14 0x90170110
0x15 0x0321101f
0x16 0x03211020
0x18 0x40030008
0x19 0x03a11030
0x1a 0x41f0
0x1b 0x41f0
0x1d 0x4101
0x1e 0x41f0
0x1f 0x41f0
/sys/class/sound/hwC1D0/driver_pin_configs:
/sys/class/sound/hwC1D0/user_pin_configs:
0x12 0x99a30140
0x14 0x90170110
0x15 0x0321101f
0x16 0x03211020
0x18 0x40030008
0x19 0x03a11030
0x1a 0x41f0
0x1b 0x41f0
0x1d 0x4101
0x1e 0x41f0
0x1f 0x41f0
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1516025/comments/8
On 2015-11-14T13:45:01+00:00 imranmohd72 wrote:
#define assoc_of_nid(c,p)
get_defcfg_association(snd_hda_codec_get_pincfg(c,p))
if ((cfg->speaker_outs == 2) && (cfg->hp_outs == 2))
if (cfg->line_out_type == AUTO_PIN_HP_OUT)
for(i=0; i<2; i++)
if (assoc_of_nid(codec,cfg->line_out_pins[i]) >
assoc_of_nid(codec,cfg->speaker_pins[i]))
badness++;
add the above in fill_and_eval_dacs() in hda_generic.c after
if ( spec->mixer_nid) {
}
this increase badness of cfg->line_out_type == AUTO_PIN_HP_OUT by one
when the second headphone have higher def association than subwoofer ,
driver create speaker and bass speaker volume controls and headphone
volume control for headset and headphone
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1516025/comments/9
On 2015-11-14T13:53:10+00:00 imranmohd72 wrote:
driver seem hardcode to use first pin spec->gen.autocfg.hp_pins[0] as hp
of the headset
and imux_pin to determine the selected mic
this mean that if you set the correct pin default of headset mic
(headset mic phantom jack)
you can select internal mic, headset mic or mic jack manually using the
capture source control
static void alc_update_headset_mode(struct hda_codec *codec)
{
struct alc_spec *spec = codec->spec;
hda_nid_t mux_pin = spec->gen.imux_pins[spec->gen.cur_mux[0]];
hda_nid_t hp_pin = spec->gen.autocfg.hp_pins[0];
int new_headset_mode;
if (!snd_hda_jack_detect(codec, hp_pin))
new_headset_mode = ALC_HEADSET_MODE_UNPLUGGED;
else if (mux_pin == spec->headset_mic_pin)
new_headset_mode = ALC_HEADSET_MODE_HEADSET;
else if (mux_pin == spec->headphone_mic_pin)
new_headset_mode = ALC_HEADSET_MODE_MIC;
else
new_headset_mode = ALC_HEADSET_MODE_HEADPHONE;
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1516025/comments/10
On 2015-11-14T17:30:25+00:00 imranmohd72 wrote:
This bug relates to another bug report that i some one else have reported
https://bugzilla.kernel.org/show_bug.cgi?id=104901
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1516025/comments/16
On 2015-11-15T01:34:24+00:00 superquad.vortex2 wrote:
can you try the patch
https://bugs.freedesktop.org/attachment.cgi?id=117571
only those part which is needed by alienware
+static void alc668_fixup_dell_alienware(struct hda_codec *codec,
+ const struct hda_fixup *fix, int action)
+{
+ const struct hda_pintbl pincfgs[] = {
+ { 0x1a, 0x99130112 }, /* subwoofer */
+ { 0x1b, 0x03a1113c }, /* headset mic */
+ { }
+ };
+ static hda_nid_t preferred_pair[] = {
+ 0x14, 0x03,
+ 0x1a, 0x04,
+ 0x15, 0x02,
+ 0x16, 0x02,
+ 0
+ };
+ struct alc_spec *spec = codec->spec;
+
+ switch (action) {
+ case HDA_FIXUP_ACT_PRE_PROBE:
+ snd_hda_apply_pincfgs(codec, pincfgs);
+ spec->gen.preferred_dacs = preferred_pair;
+ spec->gen.hs_mic_use_hp_sense = 1;
+ spec->parse_flags |= HDA_PINCFG_HEADSET_MIC;
+ break;
+ case HDA_FIXUP_ACT_PROBE:
+
[Kernel-packages] [Bug 1993120] Re: armhf kernel compiled with gcc-12 fails to boot on pi 3/2
Hey, is there anything that needs to be fixed for gcc-12 here? Or was this kernel specific? Can someone confirm? ** Changed in: gcc-12 (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/1993120 Title: armhf kernel compiled with gcc-12 fails to boot on pi 3/2 Status in gcc-12 package in Ubuntu: Incomplete Status in linux package in Ubuntu: Invalid Status in linux-raspi package in Ubuntu: Fix Released Status in gcc-12 source package in Kinetic: New Status in linux source package in Kinetic: Fix Committed Status in linux-raspi source package in Kinetic: Invalid Bug description: Kinetic 5.19 kernels compiled with gcc-12 for armhf don't boot or hang on Pi 3 and 2. Seems to work fine on Pi 4. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gcc-12/+bug/1993120/+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 1990964] Re: FTBFS on kinetic
The attachment "new upstream release 5.19" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team. [This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.] ** Tags added: patch -- 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/1990964 Title: FTBFS on kinetic Status in linux package in Ubuntu: Fix Released Status in strace package in Ubuntu: Triaged Bug description: As can be seen in [1], strace FTBFS in kinetic: this is caused by the kernel headers (linux-libc-dev) which do not define F_GETLK64 and other on 64b builds because the kernel contains a bogus commit (306f7cc1e906 "uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in fcntl.h"). This commit actually did the opposite of what it was supposed to do, namely defining those macros even on 64b builds. There is an attempt here to fix this which was not merged yet: https://lore.kernel.org/lkml/cajf2gtqtnmoeb62-63ou8y4dbrdym7iztdtfluxx9u0ltwu...@mail.gmail.com/T/ [1]: https://launchpadlibrarian.net/625441996/buildlog_ubuntu-kinetic- amd64.strace_5.16-0ubuntu4_BUILDING.txt.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1990964/+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 1993120] Re: armhf kernel compiled with gcc-12 fails to boot on pi 3/2
Is there actually an issue in gcc-12 here? Looking at the patch Juerg linked to, it appears to be a kernel issue only? -- 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/1993120 Title: armhf kernel compiled with gcc-12 fails to boot on pi 3/2 Status in gcc-12 package in Ubuntu: Incomplete Status in linux package in Ubuntu: Invalid Status in linux-raspi package in Ubuntu: Fix Released Status in gcc-12 source package in Kinetic: New Status in linux source package in Kinetic: Fix Committed Status in linux-raspi source package in Kinetic: Invalid Bug description: Kinetic 5.19 kernels compiled with gcc-12 for armhf don't boot or hang on Pi 3 and 2. Seems to work fine on Pi 4. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gcc-12/+bug/1993120/+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 1981433] Re: [Asus Zenbook UX3402ZA] Sound doesn't work at all
Sorry. I accidentally clicked on fix released button . i also try to found solution last 2 months. but not got any solution. Please changed the bug status.. i can't change access from my side now. -- 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/1981433 Title: [Asus Zenbook UX3402ZA] Sound doesn't work at all Status in linux package in Ubuntu: Fix Released Bug description: Sound/speakers don't work at all on Asus Zenbook 14 OLED and other similar models with Realtek ALC294. No solution works. Audio is not muted, tried adding snd-hda arguments - no dice. This has been reported numerous times, when will a fix finally be rolled out?! ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: linux-image-5.15.0-41-generic 5.15.0-41.44 ProcVersionSignature: Ubuntu 5.15.0-41.44-generic 5.15.39 Uname: Linux 5.15.0-41-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: martin 1730 F pulseaudio CRDA: N/A CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Tue Jul 12 13:57:05 2022 InstallationDate: Installed on 2022-07-12 (0 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) MachineType: ASUSTeK COMPUTER INC. Zenbook UX3402ZA_UX3402ZA ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-41-generic root=UUID=40c924aa-99ad-4770-a66d-33d3359f6053 ro quiet splash vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-5.15.0-41-generic N/A linux-backports-modules-5.15.0-41-generic N/A linux-firmware 20220329.git681281e4-0ubuntu3.2 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 06/15/2022 dmi.bios.release: 5.25 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: UX3402ZA.305 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: UX3402ZA dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: 1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 31 dmi.chassis.vendor: ASUSTeK COMPUTER INC. dmi.chassis.version: 1.0 dmi.ec.firmware.release: 3.5 dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvrUX3402ZA.305:bd06/15/2022:br5.25:efr3.5:svnASUSTeKCOMPUTERINC.:pnZenbookUX3402ZA_UX3402ZA:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX3402ZA:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct31:cvr1.0:sku: dmi.product.family: Zenbook dmi.product.name: Zenbook UX3402ZA_UX3402ZA dmi.product.version: 1.0 dmi.sys.vendor: ASUSTeK COMPUTER INC. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1981433/+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 1990964] Re: FTBFS on kinetic
Attached is a patch to use strace 5.19 in order to match kernel 5.19. It also reduces delta with upstream sources for packaging and in particular it fixes debian/copyright (strace is now LGPL >= 2.1). ** Patch added: "new upstream release 5.19" https://bugs.launchpad.net/ubuntu/+source/strace/+bug/1990964/+attachment/5632653/+files/strace_5.19-0ubuntu1.debdiff -- 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/1990964 Title: FTBFS on kinetic Status in linux package in Ubuntu: Fix Released Status in strace package in Ubuntu: Triaged Bug description: As can be seen in [1], strace FTBFS in kinetic: this is caused by the kernel headers (linux-libc-dev) which do not define F_GETLK64 and other on 64b builds because the kernel contains a bogus commit (306f7cc1e906 "uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in fcntl.h"). This commit actually did the opposite of what it was supposed to do, namely defining those macros even on 64b builds. There is an attempt here to fix this which was not merged yet: https://lore.kernel.org/lkml/cajf2gtqtnmoeb62-63ou8y4dbrdym7iztdtfluxx9u0ltwu...@mail.gmail.com/T/ [1]: https://launchpadlibrarian.net/625441996/buildlog_ubuntu-kinetic- amd64.strace_5.16-0ubuntu4_BUILDING.txt.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1990964/+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 1981433] Re: [Asus Zenbook UX3402ZA] Sound doesn't work at all
** Changed in: linux (Ubuntu) Status: Confirmed => 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/1981433 Title: [Asus Zenbook UX3402ZA] Sound doesn't work at all Status in linux package in Ubuntu: Fix Released Bug description: Sound/speakers don't work at all on Asus Zenbook 14 OLED and other similar models with Realtek ALC294. No solution works. Audio is not muted, tried adding snd-hda arguments - no dice. This has been reported numerous times, when will a fix finally be rolled out?! ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: linux-image-5.15.0-41-generic 5.15.0-41.44 ProcVersionSignature: Ubuntu 5.15.0-41.44-generic 5.15.39 Uname: Linux 5.15.0-41-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: martin 1730 F pulseaudio CRDA: N/A CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Tue Jul 12 13:57:05 2022 InstallationDate: Installed on 2022-07-12 (0 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) MachineType: ASUSTeK COMPUTER INC. Zenbook UX3402ZA_UX3402ZA ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-41-generic root=UUID=40c924aa-99ad-4770-a66d-33d3359f6053 ro quiet splash vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-5.15.0-41-generic N/A linux-backports-modules-5.15.0-41-generic N/A linux-firmware 20220329.git681281e4-0ubuntu3.2 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 06/15/2022 dmi.bios.release: 5.25 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: UX3402ZA.305 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: UX3402ZA dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: 1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 31 dmi.chassis.vendor: ASUSTeK COMPUTER INC. dmi.chassis.version: 1.0 dmi.ec.firmware.release: 3.5 dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvrUX3402ZA.305:bd06/15/2022:br5.25:efr3.5:svnASUSTeKCOMPUTERINC.:pnZenbookUX3402ZA_UX3402ZA:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX3402ZA:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct31:cvr1.0:sku: dmi.product.family: Zenbook dmi.product.name: Zenbook UX3402ZA_UX3402ZA dmi.product.version: 1.0 dmi.sys.vendor: ASUSTeK COMPUTER INC. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1981433/+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 1899336] Re: Thinkpad T14s (AMD) external monitors on docking station no longer detected
Thx for the update. interesting to see it was indeed a kernel/firmware issue. I'll close this for now. Please do raise further issues that are potentially a kernel issue via ubuntu-bug linux ** Changed in: linux (Ubuntu) Status: Confirmed => Fix Released ** Changed in: ubuntubudgie Status: New => 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/1899336 Title: Thinkpad T14s (AMD) external monitors on docking station no longer detected Status in Ubuntu Budgie: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: I run Ubuntu Budgie 20.04 on my Lenovo ThinkPad T14s with Ryzen 4750U processor together with the "Lenovo ThinkPad USB-C Dock (Gen 2)" (40AS0090EU). The docking station is connected via USB-C to the system, supplies it with power via USB Power Delivery and provides USB 3.1 Gen 2 (10 Gbit/s) connectivity (including an Ethernet controller and audio codec running over the USB data path), as well as support for two monitors via "DisplayPort alternate mode" of USB-C, so technically it will configure the four high-speed lanes of USB-C as one lane for SuperSpeed+ RX, one lane for SuperSpeed+ TX, and two lanes for DisplayPort 1.4, the latter of which the docking station will then demultiplex onto two full-size DisplayPort connectors like an MST hub. So far, external monitors have worked fine most of the time. However, for a couple of days now, I cannot get the system to detect the external monitors connected to my docking station anymore. The "BIOS" (EFI) boot screen (with the Lenovo logo) still shows up on the external monitors. However, both the LUKS/dm-crypt pre-boot- authentication screen (since I use full-disk-encryption) and also the desktop after login show up on the internal display, even with the laptop connected to the docking station, so it appears like the kernel no longer detects the monitors connecting via "DisplayPort alternate mode". Yesterday, I could get the monitors to show up by disconnecting the laptop from the docking station and reconnecting it again. Today, not even this appears to work. Sometimes the external monitors are detected (and shown as "enabled") in the display settings of Budgie, sometimes they do not even show up. Even when they show up and are enabled, nothing is displayed on them. The monitors say they do not receive a signal and I should check the connection. Unplugging and replugging the cables from the docking station to the monitors does not change anything. Audio, Ethernet and USB runs fine over the docking station, just DisplayPort does not. This is obviously very bad, since I now have to work on the internal display even with the laptop docked. I have the "amdgpu.exp_hw_support=1" in my kernel arguments (*) and the Ryzen 4000 GPU appears to be recognized. $ lspci -k 06:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Renoir (rev d1) Subsystem: Lenovo Renoir Kernel driver in use: amdgpu Kernel modules: amdgpu $ (*) When I installed Ubuntu Budgie 20.04, I needed to add this in order to extend my desktop over the two external monitors. Without this argument, the system only showed a single display in the settings, the same content was displayed on all connected monitors (mirrored) and there was no way to change that. I have attached parts of "dmesg" output which I deem relevant. $ uname -a Linux thinkpad-t14s 5.4.0-48-generic #52-Ubuntu SMP Thu Sep 10 10:58:49 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux $ --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu27.9 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: Budgie:GNOME DistroRelease: Ubuntu 20.04 InstallationDate: Installed on 2020-07-27 (75 days ago) InstallationMedia: Ubuntu-Budgie 20.04 LTS "Focal Fossa" - Release amd64 (20200423) MachineType: LENOVO 20UH001AGE Package: linux (not installed) ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-48-generic root=UUID=5b605ccb-8a29-46ee-b571-e0d61a323457 ro quiet splash amdgpu.exp_hw_support=1 vt.handoff=7 ProcVersionSignature: Ubuntu 5.4.0-48.52-generic 5.4.60 RelatedPackageVersions: linux-restricted-modules-5.4.0-48-generic N/A linux-backports-modules-5.4.0-48-generic N/A linux-firmware1.187.3 Tags: focal Uname: Linux 5.4.0-48-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm audio cdrom dip lpadmin lxd plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 06/11/2020 dmi.bios.vendor: LENOVO dmi.bios.version: R1CET36W(1.05 ) dmi.board.asset.tag: Not Available dmi.board.name: 20UH001AGE dmi.board.vendor: LENOVO dmi.board.version: Not Defined dmi.chassis.asset.tag: No Asset
[Kernel-packages] [Bug 1997841] [NEW] More dkms fixes for exact cc compiler
Public bug reported: [ Impact ] * Previously https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/1991664 has fixed up some dkms modules that use makefiles without setting a CC= variable inside them. However, there is a class of dkms modules that set a CC= variable inside the makefile, and then the environment variable is ignored, thus resulting in hwe-5.19 dkms modules to FTBFS. * Fix those by setting MAKEFLAGS="--environment-overrides" to really ensure that environmental variable compiler is really being used. Observe the following: $ cat Makefile.just-cc all: echo $(CC) $ cat Makefile.cc-set CC=cc-set-in-makefile all: echo $(CC) # cmdline override works in both cases $ make -f Makefile.just-cc CC=make-var-cmdline echo make-var-cmdline make-var-cmdline $ make -f Makefile.cc-set CC=make-var-cmdline echo make-var-cmdline make-var-cmdline # environment/shell variable override only works in one of them $ CC=env-cc make -f Makefile.just-cc echo env-cc env-cc $ CC=env-cc make -f Makefile.cc-set echo cc-set-in-makefile cc-set-in-makefile # unless environment-overrides is set $ MAKEFLAGS=--environment-overrides CC=env-cc make -f Makefile.cc-set echo env-cc env-cc [ Test Plan ] * Divert /usr/bin/gcc to /bin/false $ sudo ln -sf /bin/false /usr/bin/gcc * Install a v5.19 kernel that must be built with gcc-12 and a dkms module that uses a CC variable set inside its makefile $ sudo apt install linux-virtual-hwe-22.04-edge gost-crypto-dkms * Check that dkms status has the module successfully installed for v5.19 kernel $ dkms status [ Where problems could occur ] * dkms cleans environment of all tool-chain related variables already, but MAKEFLAGS=--environment-overrides may result in additional/new/unexpected variables leaking into the dkms module build, which were previously ignored. * A better solution might be for our kernel builds to emit a makefile snippet that is included by the Kbuild makefiles, but that too will only cover a subset of dkms modules, not all of them. * It might be nice if environment-overrides command line option of make accepted a list of allowed variables that are desired to be honored from the environment. [ Other Info ] * Any better suggestions of how to handle toolchain export would be welcome here, as this is starting to be silly. ** Affects: dkms (Ubuntu) Importance: Undecided Status: New ** Affects: dkms (Ubuntu Jammy) Importance: Undecided Status: New ** Affects: dkms (Ubuntu Kinetic) Importance: Undecided Status: New ** Affects: dkms (Ubuntu Lunar) Importance: Undecided Status: New ** Also affects: dkms (Ubuntu Lunar) Importance: Undecided Status: New ** Also affects: dkms (Ubuntu Kinetic) Importance: Undecided Status: New ** Also affects: dkms (Ubuntu Jammy) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to dkms in Ubuntu. https://bugs.launchpad.net/bugs/1997841 Title: More dkms fixes for exact cc compiler Status in dkms package in Ubuntu: New Status in dkms source package in Jammy: New Status in dkms source package in Kinetic: New Status in dkms source package in Lunar: New Bug description: [ Impact ] * Previously https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/1991664 has fixed up some dkms modules that use makefiles without setting a CC= variable inside them. However, there is a class of dkms modules that set a CC= variable inside the makefile, and then the environment variable is ignored, thus resulting in hwe-5.19 dkms modules to FTBFS. * Fix those by setting MAKEFLAGS="--environment-overrides" to really ensure that environmental variable compiler is really being used. Observe the following: $ cat Makefile.just-cc all: echo $(CC) $ cat Makefile.cc-set CC=cc-set-in-makefile all: echo $(CC) # cmdline override works in both cases $ make -f Makefile.just-cc CC=make-var-cmdline echo make-var-cmdline make-var-cmdline $ make -f Makefile.cc-set CC=make-var-cmdline echo make-var-cmdline make-var-cmdline # environment/shell variable override only works in one of them $ CC=env-cc make -f Makefile.just-cc echo env-cc env-cc $ CC=env-cc make -f Makefile.cc-set echo cc-set-in-makefile cc-set-in-makefile # unless environment-overrides is set $ MAKEFLAGS=--environment-overrides CC=env-cc make -f Makefile.cc-set echo env-cc env-cc [ Test Plan ] * Divert /usr/bin/gcc to /bin/false $ sudo ln -sf /bin/false /usr/bin/gcc * Install a v5.19 kernel that must be built with gcc-12 and a dkms module that uses a CC variable set inside its makefile $ sudo apt install linux-virtual-hwe-22.04-edge gost-crypto-dkms * Check that dkms status has the module successfully installed for v5.19 kernel $ dkms status
[Kernel-packages] [Bug 1997764] Re: igb driver crashes kernel when receiving jumbo frame UDP packets with all zeros
here a dmesg output before the system freezes ** Attachment added: "kernel_bug.txt" https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.15/+bug/1997764/+attachment/5632652/+files/kernel_bug.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed-hwe-5.15 in Ubuntu. https://bugs.launchpad.net/bugs/1997764 Title: igb driver crashes kernel when receiving jumbo frame UDP packets with all zeros Status in linux-signed-hwe-5.15 package in Ubuntu: New Bug description: With a high MTU (9000) set on the interface, sending packets containing over ~3000 zero bytes to a network card using the igb driver results in broken packets or in the worst case for some packet sizes even leads to kernel panics or full freeze. So far I observed this for Intel I350 and I210 network cards which use the igb driver. This is easy to reproduce: * set MTU to 9000 * send ping of death: ping -M do -p 00 3016 -> kernel panic or complete freeze of system If the data is not zero, it works fine: ping -M do -p ff 3016 Depending on packet length: * < 3000: fine * 3016: panic/freeze * > 3030: packet not complete I also tested this with the following kernel versions: * 5.8.0-63-generic -> OK * 5.11.0-46-generic -> OK * 5.13.0-52-generic -> broken * 5.15.0-41-generic -> broken * 5.19.5-051905-generic mainline -> broken We noticed that since we have GigE Vision cameras which send the data via UDP with packet sizes up to 9000. When we turned off the light (and hence many bytes in the payload were zero), the packets would not be complete anymore (checked with tcpdump/wireshark) or even lead to kernel panics. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.15.0-53-generic 5.15.0-53.59~20.04.1 ProcVersionSignature: Ubuntu 5.15.0-53.59~20.04.1-generic 5.15.64 Uname: Linux 5.15.0-53-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.25 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Nov 24 13:16:00 2022 SourcePackage: linux-signed-hwe-5.15 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.15/+bug/1997764/+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 1899336] Re: Thinkpad T14s (AMD) external monitors on docking station no longer detected
The issue appears to be fixed (at least for me) with the latest firmware. - UEFI Version 1.14 (R1CUJ72W), issued on 2022-07-29. - USB-Docking (Gen 2) Firmware Version 1.1.18, issued on 2022-09-14. (I'm on Ubuntu 22.04 LTS now though, no longer 20.04 LTS.) The system now sporadically "drops" the Realtek Ethernet controller instead. (It disconnects from the bus and keeps getting reset.) This can be brought up again reliably though by shortly power-cycling the docking station. (It's best to shortly interrupt power to the dock, so that it comes back up before the notebook goes into suspend.) Sometimes the "dropping Ethernet controller" will "only" cause a network interruption, while sometimes, it will freeze kworkers and therefore the system. Power-cycling the dock will bring Ethernet connectivity back and unfreeze the system. I might create another bug report for this issue. Just wanted to report back on the display issue that it appears to be fixed with most recent firmware, but there appear to be other regressions. -- 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/1899336 Title: Thinkpad T14s (AMD) external monitors on docking station no longer detected Status in Ubuntu Budgie: New Status in linux package in Ubuntu: Confirmed Bug description: I run Ubuntu Budgie 20.04 on my Lenovo ThinkPad T14s with Ryzen 4750U processor together with the "Lenovo ThinkPad USB-C Dock (Gen 2)" (40AS0090EU). The docking station is connected via USB-C to the system, supplies it with power via USB Power Delivery and provides USB 3.1 Gen 2 (10 Gbit/s) connectivity (including an Ethernet controller and audio codec running over the USB data path), as well as support for two monitors via "DisplayPort alternate mode" of USB-C, so technically it will configure the four high-speed lanes of USB-C as one lane for SuperSpeed+ RX, one lane for SuperSpeed+ TX, and two lanes for DisplayPort 1.4, the latter of which the docking station will then demultiplex onto two full-size DisplayPort connectors like an MST hub. So far, external monitors have worked fine most of the time. However, for a couple of days now, I cannot get the system to detect the external monitors connected to my docking station anymore. The "BIOS" (EFI) boot screen (with the Lenovo logo) still shows up on the external monitors. However, both the LUKS/dm-crypt pre-boot- authentication screen (since I use full-disk-encryption) and also the desktop after login show up on the internal display, even with the laptop connected to the docking station, so it appears like the kernel no longer detects the monitors connecting via "DisplayPort alternate mode". Yesterday, I could get the monitors to show up by disconnecting the laptop from the docking station and reconnecting it again. Today, not even this appears to work. Sometimes the external monitors are detected (and shown as "enabled") in the display settings of Budgie, sometimes they do not even show up. Even when they show up and are enabled, nothing is displayed on them. The monitors say they do not receive a signal and I should check the connection. Unplugging and replugging the cables from the docking station to the monitors does not change anything. Audio, Ethernet and USB runs fine over the docking station, just DisplayPort does not. This is obviously very bad, since I now have to work on the internal display even with the laptop docked. I have the "amdgpu.exp_hw_support=1" in my kernel arguments (*) and the Ryzen 4000 GPU appears to be recognized. $ lspci -k 06:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Renoir (rev d1) Subsystem: Lenovo Renoir Kernel driver in use: amdgpu Kernel modules: amdgpu $ (*) When I installed Ubuntu Budgie 20.04, I needed to add this in order to extend my desktop over the two external monitors. Without this argument, the system only showed a single display in the settings, the same content was displayed on all connected monitors (mirrored) and there was no way to change that. I have attached parts of "dmesg" output which I deem relevant. $ uname -a Linux thinkpad-t14s 5.4.0-48-generic #52-Ubuntu SMP Thu Sep 10 10:58:49 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux $ --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu27.9 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: Budgie:GNOME DistroRelease: Ubuntu 20.04 InstallationDate: Installed on 2020-07-27 (75 days ago) InstallationMedia: Ubuntu-Budgie 20.04 LTS "Focal Fossa" - Release amd64 (20200423) MachineType: LENOVO 20UH001AGE Package: linux (not installed) ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-48-generic root=UUID=5b605ccb-8a29-46ee-b571-e0d61a323457 ro quiet splash amdgpu.exp_hw_support=1 vt.handoff=7
[Kernel-packages] [Bug 1908139] Re: ThinkPad T14s external display not working on ThinkPad USB-C Dock Gen2
The issue with monitors "dropping" appears to be fixed for me with the latest firmware. - UEFI Version 1.14 (R1CUJ72W), issued on 2022-07-29. - USB-Docking (Gen 2) Firmware Version 1.1.18, issued on 2022-09-14. However, I now have the issue of my Ethernet connection "dropping" shortly after boot. The Ethernet controller "disappears" from the bus, apparently due to some power management event. (Something regarding "link power management" is logged before it "disappears".) It seems like the kernel module for the Realtek chip then cyclically tries to reset the controller and upload firmware to it, which fails, causing it to reset again and so on. Sometimes it seems like this cyclical reset can even lock up the kernel and therefore the system. Power-cycling the docking station solves the issue, as it apparently causes the Ethernet controller to get initialized correctly (accepting the temporary firmware upload) and the link coming up. It also "unfreezes" the system if it is frozen due to being stuck in the "controller reset cycle". This is on Ubuntu 22.04 LTS though. There's really something weird going on with the high-speed busses on these Ryzen-based systems it seems, and depending on the UEFI, it appears to affect different parts of the system. -- 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/1908139 Title: ThinkPad T14s external display not working on ThinkPad USB-C Dock Gen2 Status in linux package in Ubuntu: Fix Released Bug description: laptop: ThinkPad T14s Gen 1 - AMD Ryzen 7 PRO 4750U docking station: ThinkPad USB-C Dock 2. Gen. external display: NE MultiSync EA275UHD OS: Ubuntu 20.10 - kernel 5.8.0 Plugging the external display into one of the docking station's two DisplayPort connectors leads to the screen resolution changing on the laptop's builtin display and the external display waking up but showing no picture and displaying "no-signal" after a bit. Plugging the external display into the docking station's HDMI connector leads to no visible reaction on either the external nor the builtin display. Plugging the external display into the laptop's builtin HDMI connector works as expected. The external display is recognized and shows an image. I have recorded the output on `dmesg` during the steps mentioned above and inserted explanations using `echo MSG >/dev/kmsg`. The output follows at the end of the message. I believe `ubuntu-bug` should also attach the full log. All above modes of connection work as expected with the same laptop, dock, and display on Windows 10 (installed as dual boot along side Ubuntu). All above modes of connection also work as expected with an older laptop (ThinkPad T470s - Ubuntu 20.04 - kernel 5.4.0), and the same dock and display. This leads me to believe that this is not a hardware issue. The following bug seems related, but seems to have been observed on faulty hardware according to its author. Therefore, I decided to open a separate bug report. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1899336 ``` [ 343.372511] plugging DisplayPort into dock port 1 [ 352.666113] [drm] DP Alt mode state on HPD: 1 [ 352.749192] [drm] DM_MST: starting TM on aconnector: 2105a317 [id: 75] [ 352.858482] [drm] amdgpu_dm_irq_schedule_work FAILED src 9 [ 352.888400] [drm] amdgpu_dm_irq_schedule_work FAILED src 9 [ 352.892555] [drm] amdgpu_dm_irq_schedule_work FAILED src 9 [ 352.896719] [drm] amdgpu_dm_irq_schedule_work FAILED src 9 [ 352.900876] [drm] amdgpu_dm_irq_schedule_work FAILED src 9 [ 352.905596] [drm] amdgpu_dm_irq_schedule_work FAILED src 9 [ 352.910323] [drm] amdgpu_dm_irq_schedule_work FAILED src 9 [ 352.914485] [drm] amdgpu_dm_irq_schedule_work FAILED src 9 [ 377.353566] plugged in - no signal [ 396.728970] unplugging [ 403.001418] [drm] DM_MST: stopping TM on aconnector: 2105a317 [id: 75] [ 415.576397] unplugged [ 431.500729] plugging DisplayPort into dock port 2 [ 437.607724] [drm] DP Alt mode state on HPD: 1 [ 437.681116] [drm] DM_MST: starting TM on aconnector: 2105a317 [id: 75] [ 437.790303] [drm] amdgpu_dm_irq_schedule_work FAILED src 9 [ 437.820138] [drm] amdgpu_dm_irq_schedule_work FAILED src 9 [ 437.824305] [drm] amdgpu_dm_irq_schedule_work FAILED src 9 [ 437.828462] [drm] amdgpu_dm_irq_schedule_work FAILED src 9 [ 437.832619] [drm] amdgpu_dm_irq_schedule_work FAILED src 9 [ 437.837029] [drm] amdgpu_dm_irq_schedule_work FAILED src 9 [ 437.841984] [drm] amdgpu_dm_irq_schedule_work FAILED src 9 [ 437.846144] [drm] amdgpu_dm_irq_schedule_work FAILED src 9 [ 458.999849] plugged in - no signal [ 465.702949] unplugging [ 476.127418] [drm] DM_MST: stopping TM on aconnector: 2105a317 [id: 75] [ 476.956491] [drm] Failed to add display topology, DTM TA is not
[Kernel-packages] [Bug 1997764] Re: igb driver crashes kernel when receiving jumbo frame UDP packets with all zeros
** Attachment added: "lspci-vvnn.log" https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.15/+bug/1997764/+attachment/5632632/+files/lspci-vvnn.log -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed-hwe-5.15 in Ubuntu. https://bugs.launchpad.net/bugs/1997764 Title: igb driver crashes kernel when receiving jumbo frame UDP packets with all zeros Status in linux-signed-hwe-5.15 package in Ubuntu: New Bug description: With a high MTU (9000) set on the interface, sending packets containing over ~3000 zero bytes to a network card using the igb driver results in broken packets or in the worst case for some packet sizes even leads to kernel panics or full freeze. So far I observed this for Intel I350 and I210 network cards which use the igb driver. This is easy to reproduce: * set MTU to 9000 * send ping of death: ping -M do -p 00 3016 -> kernel panic or complete freeze of system If the data is not zero, it works fine: ping -M do -p ff 3016 Depending on packet length: * < 3000: fine * 3016: panic/freeze * > 3030: packet not complete I also tested this with the following kernel versions: * 5.8.0-63-generic -> OK * 5.11.0-46-generic -> OK * 5.13.0-52-generic -> broken * 5.15.0-41-generic -> broken * 5.19.5-051905-generic mainline -> broken We noticed that since we have GigE Vision cameras which send the data via UDP with packet sizes up to 9000. When we turned off the light (and hence many bytes in the payload were zero), the packets would not be complete anymore (checked with tcpdump/wireshark) or even lead to kernel panics. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.15.0-53-generic 5.15.0-53.59~20.04.1 ProcVersionSignature: Ubuntu 5.15.0-53.59~20.04.1-generic 5.15.64 Uname: Linux 5.15.0-53-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.25 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Nov 24 13:16:00 2022 SourcePackage: linux-signed-hwe-5.15 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.15/+bug/1997764/+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 1997764] Re: igb driver crashes kernel when receiving jumbo frame UDP packets with all zeros
On a tainted kernel (proprietary nvidia driver installed) I got this in the kernel log earlier: Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.196527] [ cut here ] Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.196533] kernel BUG at include/linux/skbuff.h:2338! Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.202252] invalid opcode: [#1] SMP NOPTI Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.207232] CPU: 0 PID: 0 Comm: swapper/0 Tainted: P OE 5.13.0-52-generic #59~20.04.1-Ubuntu Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.217813] Hardware name: Neousys Technology Inc. Nuvo-7000 Series/NVS-7000, BIOS Build190905 09/05/2019 Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.228275] RIP: 0010:eth_type_trans+0xe3/0x170 Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.233231] Code: 28 00 00 00 0f 85 a2 00 00 00 48 83 c4 18 5b 5d c3 a8 01 75 42 0f b6 87 80 00 00 00 83 e0 f8 83 c8 03 88 87 80 00 00 00 eb 91 <0f> 0b 8b 47 70 2b 47 74 48 8b 97 c8 00 00 00 83 f8 01 7e 3e 48 85 Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.253555] RSP: 0018:b2c380003db0 EFLAGS: 00010207 Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.259093] RAX: 0bd4 RBX: 97a4a36340d0 RCX: 00018043 Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.266640] RDX: 97a490244000 RSI: 97a490244000 RDI: 97a58ba87000 Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.274184] RBP: b2c380003dd0 R08: fff2 R09: 1000 Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.281754] R10: 97a4a3634ec0 R11: 00c0 R12: 97a490225340 Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.289320] R13: 97a4a1b702f0 R14: 97a58ba87000 R15: 1000 Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.296940] FS: () GS:97abdc20() knlGS: Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.305538] CS: 0010 DS: ES: CR0: 80050033 Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.311613] CR2: 7fba79b518b0 CR3: 00031b810001 CR4: 003706f0 Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.319171] Call Trace: Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.321771] Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.323914] igb_clean_rx_irq+0x3b2/0xca0 [igb] Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.328731] igb_poll+0x5c/0x350 [igb] Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.332742] __napi_poll+0x2e/0x140 Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.336470] net_rx_action+0x23f/0x290 Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.340447] __do_softirq+0xcc/0x282 Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.344244] irq_exit_rcu+0xa4/0xb0 Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.347953] common_interrupt+0x8a/0xa0 Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.352056] Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.354316] Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.356568] asm_common_interrupt+0x1e/0x40 Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.361014] RIP: 0010:cpuidle_enter_state+0xcc/0x360 Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.366233] Code: 3d 51 84 0b 6d e8 e4 67 78 ff 49 89 c6 0f 1f 44 00 00 31 ff e8 35 73 78 ff 80 7d d7 00 0f 85 01 01 00 00 fb 66 0f 1f 44 00 00 <45> 85 ff 0f 88 0d 01 00 00 49 63 c7 4c 2b 75 c8 48 8d 14 40 48 8d Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.386143] RSP: 0018:94403dc8 EFLAGS: 0246 Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.391695] RAX: 97abdc234e40 RBX: 0004 RCX: 001f Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.399260] RDX: RSI: 2424 RDI: Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.406845] RBP: 94403e00 R08: 00f92cae429b R09: 94650e60 Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.414412] R10: 97abdc233864 R11: 97abdc233844 R12: d2c37fa00300 Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.421988] R13: 94650e60 R14: 00f92cae429b R15: 0004 Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.429580] ? cpuidle_enter_state+0xbb/0x360 Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.434225] cpuidle_enter+0x2e/0x40 Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.438030] call_cpuidle+0x23/0x40 Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.441746] do_idle+0x1e6/0x260 Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.445161] cpu_startup_entry+0x20/0x30 Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.449340] rest_init+0xb8/0xba Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.452771] arch_call_rest_init+0xe/0x1b Sep 15 10:44:13 rc-cube-78d0042d744c kernel: [ 1070.457026] start_kernel+0x6ae/0x6d4 Sep 15 10:44:13 rc-cube-78d0042d744c kernel:
[Kernel-packages] [Bug 1653506] Re: Not possible to connect to Ubuntu from remote device
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: bluez (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1653506 Title: Not possible to connect to Ubuntu from remote device Status in bluez package in Ubuntu: Confirmed Bug description: The Ubuntu is not letting the remote device in in case when the remote device is the initiator of the connection request. It drops connection request on the L2CAP level with 'security block' error code. The step-by-step example: 1. Ubuntu pairs & connects to remote device 2. Ubuntu disconnects 3. Remote device tries to reconnect It is seen from the HCI trace that the root cause is the problem in finding the agent that could carry the auth process on. In this case however the agent has been registered previously. The HCI trace: > ACL Data RX: Handle 12 flags 0x02 dlen 12 [hci0] 941.214394 L2CAP: Connection Request (0x02) ident 38 len 4 PSM: 25 (0x0019) Source CID: 65 < ACL Data TX: Handle 12 flags 0x00 dlen 16 [hci0] 941.214473 L2CAP: Connection Response (0x03) ident 38 len 8 Destination CID: 64 Source CID: 65 Result: Connection pending (0x0001) Status: Authorization pending (0x0002) = bluetoothd: Authentication attempt without agent [hci0] 941.214871 = bluetoothd: Access denied: org.bluez.Error.Rejected 941.214921 < ACL Data TX: Handle 12 flags 0x00 dlen 16 [hci0] 941.214916 L2CAP: Connection Response (0x03) ident 38 len 8 Destination CID: 64 Source CID: 65 Result: Connection refused - security block (0x0003) Status: No further information available (0x) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1653506/+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 1997763] [NEW] WARNING: CPU: 3 PID: 34 at /build/linux-raspi2-xwwT5i/linux-raspi2-4.15.0/drivers/spi/spidev.c:738 spidev_probe+0x13c/0x1f8
Public bug reported: [Impact] Current 4.15 raspi2 kernel emits the following warnings when the spidev driver is loaded: kernel: [2.957689] WARNING: CPU: 3 PID: 34 at /build/linux-raspi2-xwwT5i/linux-raspi2-4.15.0/drivers/spi/spidev.c:738 spidev_probe+0x13c/0x1f8 kernel: [4.527294] WARNING: CPU: 3 PID: 34 at /build/linux-raspi2-xwwT5i/linux-raspi2-4.15.0/drivers/spi/spidev.c:738 spidev_probe+0x13c/0x1f8 kernel: [2.957668] WARNING: CPU: 3 PID: 34 at /build/linux-raspi2-xwwT5i/linux-raspi2-4.15.0/drivers/spi/spidev.c:738 spidev_probe+0x13c/0x1f8 kernel: [4.525991] WARNING: CPU: 3 PID: 34 at /build/linux-raspi2-xwwT5i/linux-raspi2-4.15.0/drivers/spi/spidev.c:738 spidev_probe+0x13c/0x1f8 [Test Case] Boot 4.15 raspi2 kernel on a Pi 2/3 and load the spidev modules [Fix] This warning is triggered by an upstream change that wants a compatible (HW) string which is a questionable requirement for a generic driver. Caused a lot of upstream discussion with the end result that the raspi people disabled the warning in their kernel. We do the same on our newer kernels so lets backport that fix to 4.15. [Regression Potential] Changes are confined to the spidev module and only silence a warning. No negative side-effects are expected. ** Affects: linux-raspi2 (Ubuntu) Importance: Undecided Status: Invalid ** Affects: linux-raspi2 (Ubuntu Bionic) Importance: Undecided Status: Confirmed ** Also affects: linux-raspi2 (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: linux-raspi2 (Ubuntu Bionic) Status: New => Confirmed ** Changed in: linux-raspi2 (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-raspi2 in Ubuntu. https://bugs.launchpad.net/bugs/1997763 Title: WARNING: CPU: 3 PID: 34 at /build/linux-raspi2-xwwT5i/linux- raspi2-4.15.0/drivers/spi/spidev.c:738 spidev_probe+0x13c/0x1f8 Status in linux-raspi2 package in Ubuntu: Invalid Status in linux-raspi2 source package in Bionic: Confirmed Bug description: [Impact] Current 4.15 raspi2 kernel emits the following warnings when the spidev driver is loaded: kernel: [2.957689] WARNING: CPU: 3 PID: 34 at /build/linux-raspi2-xwwT5i/linux-raspi2-4.15.0/drivers/spi/spidev.c:738 spidev_probe+0x13c/0x1f8 kernel: [4.527294] WARNING: CPU: 3 PID: 34 at /build/linux-raspi2-xwwT5i/linux-raspi2-4.15.0/drivers/spi/spidev.c:738 spidev_probe+0x13c/0x1f8 kernel: [2.957668] WARNING: CPU: 3 PID: 34 at /build/linux-raspi2-xwwT5i/linux-raspi2-4.15.0/drivers/spi/spidev.c:738 spidev_probe+0x13c/0x1f8 kernel: [4.525991] WARNING: CPU: 3 PID: 34 at /build/linux-raspi2-xwwT5i/linux-raspi2-4.15.0/drivers/spi/spidev.c:738 spidev_probe+0x13c/0x1f8 [Test Case] Boot 4.15 raspi2 kernel on a Pi 2/3 and load the spidev modules [Fix] This warning is triggered by an upstream change that wants a compatible (HW) string which is a questionable requirement for a generic driver. Caused a lot of upstream discussion with the end result that the raspi people disabled the warning in their kernel. We do the same on our newer kernels so lets backport that fix to 4.15. [Regression Potential] Changes are confined to the spidev module and only silence a warning. No negative side-effects are expected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1997763/+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 1997764] [NEW] igb driver crashes kernel when receiving jumbo frame UDP packets with all zeros
Public bug reported: With a high MTU (9000) set on the interface, sending packets containing over ~3000 zero bytes to a network card using the igb driver results in broken packets or in the worst case for some packet sizes even leads to kernel panics or full freeze. So far I observed this for Intel I350 and I210 network cards which use the igb driver. This is easy to reproduce: * set MTU to 9000 * send ping of death: ping -M do -p 00 3016 -> kernel panic or complete freeze of system If the data is not zero, it works fine: ping -M do -p ff 3016 Depending on packet length: * < 3000: fine * 3016: panic/freeze * > 3030: packet not complete I also tested this with the following kernel versions: * 5.8.0-63-generic -> OK * 5.11.0-46-generic -> OK * 5.13.0-52-generic -> broken * 5.15.0-41-generic -> broken * 5.19.5-051905-generic mainline -> broken We noticed that since we have GigE Vision cameras which send the data via UDP with packet sizes up to 9000. When we turned off the light (and hence many bytes in the payload were zero), the packets would not be complete anymore (checked with tcpdump/wireshark) or even lead to kernel panics. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.15.0-53-generic 5.15.0-53.59~20.04.1 ProcVersionSignature: Ubuntu 5.15.0-53.59~20.04.1-generic 5.15.64 Uname: Linux 5.15.0-53-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.25 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Nov 24 13:16:00 2022 SourcePackage: linux-signed-hwe-5.15 UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: linux-signed-hwe-5.15 (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed-hwe-5.15 in Ubuntu. https://bugs.launchpad.net/bugs/1997764 Title: igb driver crashes kernel when receiving jumbo frame UDP packets with all zeros Status in linux-signed-hwe-5.15 package in Ubuntu: New Bug description: With a high MTU (9000) set on the interface, sending packets containing over ~3000 zero bytes to a network card using the igb driver results in broken packets or in the worst case for some packet sizes even leads to kernel panics or full freeze. So far I observed this for Intel I350 and I210 network cards which use the igb driver. This is easy to reproduce: * set MTU to 9000 * send ping of death: ping -M do -p 00 3016 -> kernel panic or complete freeze of system If the data is not zero, it works fine: ping -M do -p ff 3016 Depending on packet length: * < 3000: fine * 3016: panic/freeze * > 3030: packet not complete I also tested this with the following kernel versions: * 5.8.0-63-generic -> OK * 5.11.0-46-generic -> OK * 5.13.0-52-generic -> broken * 5.15.0-41-generic -> broken * 5.19.5-051905-generic mainline -> broken We noticed that since we have GigE Vision cameras which send the data via UDP with packet sizes up to 9000. When we turned off the light (and hence many bytes in the payload were zero), the packets would not be complete anymore (checked with tcpdump/wireshark) or even lead to kernel panics. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.15.0-53-generic 5.15.0-53.59~20.04.1 ProcVersionSignature: Ubuntu 5.15.0-53.59~20.04.1-generic 5.15.64 Uname: Linux 5.15.0-53-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.25 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Nov 24 13:16:00 2022 SourcePackage: linux-signed-hwe-5.15 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.15/+bug/1997764/+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 1987829] Re: LG Gram 12gen high CPU use when USB-C/TB is in use
Problem reproduced on Fedora 37. When charged to full, it's not spamming ACPI Errors anymore. Same hardware as OP. -- 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/1987829 Title: LG Gram 12gen high CPU use when USB-C/TB is in use Status in linux package in Ubuntu: Confirmed Bug description: LG Gram laptop 17Z90Q with a Core i7-1260P CPU. Whenever an external monitor is connected to USB-C/Thunderbolt 4, average load goes above 3.0 and the machine is getting very hot. Output from top -H shows a lot of kworker CPU usage: top - 11:45:06 up 33 min, 2 users, load average: 3,30, 3,08, 2,79 Threads: 1442 total, 2 running, 1440 sleeping, 0 stopped, 0 zombie %Cpu(s): 0,1 us, 3,7 sy, 0,0 ni, 96,1 id, 0,0 wa, 0,0 hi, 0,1 si, 0,0 st MiB Mem : 15684,6 total, 8510,2 free, 2580,8 used, 4593,6 buff/cache MiB Swap: 3815,0 total, 3815,0 free, 0,0 used. 11326,9 avail Mem PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ WCHAN COMMAND 7766 root 20 0 0 0 0 R 19,8 0,0 0:56.05 worker_th+ kworker/0:2-events 196 root 20 0 0 0 0 D 15,8 0,0 1:18.12 ec_guard kworker/u32:2+USBC000:00-con0 10237 root 20 0 0 0 0 I 12,9 0,0 0:26.44 worker_th+ kworker/0:0-events 1027 root 20 0 0 0 0 I 6,6 0,0 0:43.30 worker_th+ kworker/1:3-events 10971 root 20 0 0 0 0 I 4,0 0,0 0:00.20 worker_th+ kworker/15:0-events 175 root 20 0 0 0 0 I 2,3 0,0 0:03.24 worker_th+ kworker/11:1-events 2410 root 20 0 0 0 0 I 1,7 0,0 0:05.49 worker_th+ kworker/9:3-events Perf shows a lot of time spent inside handle_irq_event/acpi_ev_gpe_detect/acpi_hw_gpe_read. Additionally, kernel log is getting spammed with these lines every 4 seconds (but also without any USB-C device attached): [ 223.514304] ACPI Error: No handler for Region [XIN1] (f2ad4f1f) [UserDefinedRegion] (20210730/evregion-130) [ 223.514323] ACPI Error: Region UserDefinedRegion (ID=143) has no handler (20210730/exfldio-261) [ 223.514337] Initialized Local Variables for Method [_TMP]: [ 223.514339] Local0: 21495082Integer 0034 [ 223.514349] No Arguments are initialized for method [_TMP] [ 223.514354] ACPI Error: Aborting method \_SB.PC00.LPCB.LGEC.SEN2._TMP due to previous error (AE_NOT_EXIST) (20210730/psparse-529) ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: linux-image-5.15.0-46-generic 5.15.0-46.49 ProcVersionSignature: Ubuntu 5.15.0-46.49-generic 5.15.39 Uname: Linux 5.15.0-46-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: me 1678 F pulseaudio /dev/snd/controlC1: me 1678 F pulseaudio CRDA: N/A CasperMD5CheckResult: pass Date: Fri Aug 26 11:57:05 2022 InstallationDate: Installed on 2022-08-25 (1 days ago) InstallationMedia: Ubuntu 22.04.1 LTS "Jammy Jellyfish" - Release amd64 (20220809.1) MachineType: LG Electronics 17Z90Q-G.AA78N ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-46-generic root=UUID=e2f96916-a67c-432e-b687-730071271216 ro quiet splash vt.handoff=7 PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. RelatedPackageVersions: linux-restricted-modules-5.15.0-46-generic N/A linux-backports-modules-5.15.0-46-generic N/A linux-firmware 20220329.git681281e4-0ubuntu3.4 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 07/06/2022 dmi.bios.release: 0.1 dmi.bios.vendor: Phoenix Technologies Ltd. dmi.bios.version: A1ZG0380 X64 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: 17Z90Q dmi.board.vendor: LG Electronics dmi.board.version: FAB1 dmi.chassis.asset.tag: Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LG Electronics dmi.chassis.version: 0.1 dmi.ec.firmware.release: 33.0 dmi.modalias: dmi:bvnPhoenixTechnologiesLtd.:bvrA1ZG0380X64:bd07/06/2022:br0.1:efr33.0:svnLGElectronics:pn17Z90Q-G.AA78N:pvr0.1:rvnLGElectronics:rn17Z90Q:rvrFAB1:cvnLGElectronics:ct10:cvr0.1:skuEVO: dmi.product.family: LG gram PC dmi.product.name: 17Z90Q-G.AA78N dmi.product.sku: EVO dmi.product.version: 0.1 dmi.sys.vendor: LG Electronics To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1987829/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe :
[Kernel-packages] [Bug 1953554] Re: NETDEV WATCHDOG: waneth (ax88179_178a): transmit queue 0 timed out
Hi, I often have connection interrupts (mostly during video calls or, even worse, heavy database access) with a usb-c docking station using the same chipset. Same message in the syslog. Linux Mint 21, 5.15.0-53-generic, Lenovo Thinkpad P14s, other network drivers loaded: mt7921e, r8169. Had one similar issue with Wifi (Mediatek) only but unfortunately did not store the log back then. Nov 24 11:46:22 hostname kernel: [14058.991912] [ cut here ] Nov 24 11:46:22 hostname kernel: [14058.991916] NETDEV WATCHDOG: enxf8e43bb8b76c (ax88179_178a): transmit queue 0 timed out Nov 24 11:46:22 hostname kernel: [14058.991929] WARNING: CPU: 8 PID: 0 at net/sched/sch_generic.c:477 dev_watchdog+0x277/0x280 Nov 24 11:46:22 hostname kernel: [14058.991938] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace fscache netfs xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo nft_counter xt_addrtype nft_compat nf_tables nfnetlink br_netfilter bridge stp llc ccm rfcomm cmac algif_hash algif_skcipher af_alg overlay bnep sunrpc zfs(PO) zunicode(PO) zzstd(O) zlua(O) zavl(PO) icp(PO) zcommon(PO) znvpair(PO) spl(O) intel_rapl_msr intel_rapl_common btusb btrtl btbcm btintel snd_soc_dmic snd_acp3x_pdm_dma snd_acp3x_rn bluetooth snd_soc_core snd_ctl_led snd_compress edac_mce_amd ac97_bus ecdh_generic ecc snd_pcm_dmaengine snd_hda_codec_realtek mt7921e snd_hda_codec_generic mt76_connac_lib snd_hda_codec_hdmi kvm_amd mt76 kvm uvcvideo joydev snd_usb_audio thinkpad_acpi videobuf2_vmalloc snd_pci_acp6x videobuf2_memops snd_pci_acp5x think_lmi videobuf2_v4l2 nvram nls_iso8859_1 rapl serio_raw input_leds firmwar e_attributes_class wmi_bmof Nov 24 11:46:22 hostname kernel: [14058.992002] snd_usbmidi_lib ledtrig_audio mac80211 snd_hda_intel snd_seq_midi videobuf2_common snd_seq_midi_event snd_rn_pci_acp3x snd_intel_dspcfg k10temp snd_intel_sdw_acpi videodev snd_rawmidi snd_pci_acp3x snd_hda_codec mc snd_seq snd_hda_core cfg80211 snd_hwdep snd_pcm ccp libarc4 snd_seq_device snd_timer ucsi_acpi typec_ucsi typec snd soundcore platform_profile mac_hid amd_pmc sch_fq_codel msr parport_pc ppdev lp ramoops parport pstore_blk reed_solomon pstore_zone efi_pstore ip_tables x_tables autofs4 btrfs blake2b_generic xor zstd_compress raid6_pq libcrc32c ax88179_178a usbnet mii hid_generic usbhid hid dm_mirror dm_region_hash dm_log amdgpu iommu_v2 gpu_sched i2c_algo_bit drm_ttm_helper ttm drm_kms_helper syscopyarea rtsx_pci_sdmmc sysfillrect crct10dif_pclmul crc32_pclmul sysimgblt ghash_clmulni_intel nvme fb_sys_fops cec aesni_intel r8169 rc_core crypto_simd xhci_pci cryptd psmouse drm i2c_piix4 rtsx_pci nvme_core xhci_pci_renesas realt ek wmi video i2c_scmi Nov 24 11:46:22 hostname kernel: [14058.992047] CPU: 8 PID: 0 Comm: swapper/8 Tainted: P O 5.15.0-53-generic #59-Ubuntu Nov 24 11:46:22 hostname kernel: [14058.992049] Hardware name: LENOVO 21A0006VGE/21A0006VGE, BIOS R1MET49W (1.19 ) 06/27/2022 Nov 24 11:46:22 hostname kernel: [14058.992050] RIP: 0010:dev_watchdog+0x277/0x280 Nov 24 11:46:22 hostname kernel: [14058.992053] Code: eb 97 48 8b 5d d0 c6 05 07 24 69 01 01 48 89 df e8 2e 67 f9 ff 44 89 e1 48 89 de 48 c7 c7 e8 59 ad a6 48 89 c2 e8 d0 d0 19 00 <0f> 0b eb 80 e9 03 3a 23 00 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 Nov 24 11:46:22 hostname kernel: [14058.992054] RSP: 0018:aee3003a8e70 EFLAGS: 00010282 Nov 24 11:46:22 hostname kernel: [14058.992056] RAX: RBX: 970fc1c4e000 RCX: 0027 Nov 24 11:46:22 hostname kernel: [14058.992057] RDX: 9715d2020588 RSI: 0001 RDI: 9715d2020580 Nov 24 11:46:22 hostname kernel: [14058.992058] RBP: aee3003a8ea8 R08: 0003 R09: fffd8bc0 Nov 24 11:46:22 hostname kernel: [14058.992059] R10: 000a R11: 0001 R12: Nov 24 11:46:22 hostname kernel: [14058.992060] R13: 970fc02dfc80 R14: 0001 R15: 970fc1c4e4c0 Nov 24 11:46:22 hostname kernel: [14058.992061] FS: () GS:9715d200() knlGS: Nov 24 11:46:22 hostname kernel: [14058.992062] CS: 0010 DS: ES: CR0: 80050033 Nov 24 11:46:22 hostname kernel: [14058.992063] CR2: 14af00394000 CR3: 0002ce40a000 CR4: 00750ee0 Nov 24 11:46:22 hostname kernel: [14058.992064] PKRU: 5554 Nov 24 11:46:22 hostname kernel: [14058.992065] Call Trace: Nov 24 11:46:22 hostname kernel: [14058.992066] Nov 24 11:46:22 hostname kernel: [14058.992068] ? pfifo_fast_enqueue+0x160/0x160 Nov 24 11:46:22 hostname kernel: [14058.992070] call_timer_fn+0x2c/0x120 Nov 24 11:46:22 hostname kernel: [14058.992073] __run_timers.part.0+0x1e3/0x270 Nov 24 11:46:22 hostname kernel: [14058.992074] ? ktime_get+0x46/0xc0 Nov 24 11:46:22 hostname kernel: [14058.992076] ? native_x2apic_icr_read+0x20/0x20 Nov 24 11:46:22
[Kernel-packages] [Bug 1997757] [NEW] No more sound after upgrade to linux-image-6.0.0-1007-oem
Public bug reported: Description:KDE neon 5.26 Release:22.04 After upgrade from linux-image-6.0.0-1006-oem to linux-image-6.0.0-1007-oem I don't have sound anymore. I believe that the relevant dmesg message is this one, as it is not printed with the linux-image-6.0.0-1006-oem version: I think this bug is connected with this bub from Debian. https://lists.debian.org/debian-kernel/2022/10/msg00301.html Log: [5.535620] sof-audio-pci-intel-tgl :00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100 [5.535644] sof-audio-pci-intel-tgl :00:1f.3: Digital mics found on Skylake+ platform, using SOF driver [5.535650] sof-audio-pci-intel-tgl :00:1f.3: enabling device ( -> 0002) [5.535784] sof-audio-pci-intel-tgl :00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040100 [5.535850] sof-audio-pci-intel-tgl :00:1f.3: bound :00:02.0 (ops i915_audio_component_bind_ops [i915]) [5.544186] sof-audio-pci-intel-tgl :00:1f.3: use msi interrupt mode [5.605507] sof-audio-pci-intel-tgl :00:1f.3: hda codecs found, mask 5 [5.605509] sof-audio-pci-intel-tgl :00:1f.3: using HDA machine driver skl_hda_dsp_generic now [5.605511] sof-audio-pci-intel-tgl :00:1f.3: DMICs detected in NHLT tables: 2 [5.606867] sof-audio-pci-intel-tgl :00:1f.3: Firmware info: version 2:0:0-b678a [5.606869] sof-audio-pci-intel-tgl :00:1f.3: Firmware: ABI 3:20:0 Kernel ABI 3:23:0 [5.606872] sof-audio-pci-intel-tgl :00:1f.3: unknown sof_ext_man header type 3 size 0x30 [5.613329] iwlwifi :00:14.3: Detected RF HR B3, rfid=0x10a100 [5.679733] iwlwifi :00:14.3: base HW address: 8c:1d:96:08:c0:32 [5.691036] sof-audio-pci-intel-tgl :00:1f.3: Firmware info: version 2:0:0-b678a [5.691039] sof-audio-pci-intel-tgl :00:1f.3: Firmware: ABI 3:20:0 Kernel ABI 3:23:0 [5.695325] iwlwifi :00:14.3 wlp0s20f3: renamed from wlan0 [5.703514] sof-audio-pci-intel-tgl :00:1f.3: Topology: ABI 3:20:0 Kernel ABI 3:23:0 [5.703670] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: Parent card not yet available, widget card binding deferred [5.706576] snd_hda_codec_hdmi ehdaudio0D2: failed to create hda codec -12 [5.706661] snd_hda_codec_hdmi ehdaudio0D2: ASoC: error at snd_soc_component_probe on ehdaudio0D2: -12 [5.706676] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: failed to instantiate card -12 [5.706767] skl_hda_dsp_generic: probe of skl_hda_dsp_generic failed with error -12 ** Affects: linux-oem-6.0 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-oem-6.0 in Ubuntu. https://bugs.launchpad.net/bugs/1997757 Title: No more sound after upgrade to linux-image-6.0.0-1007-oem Status in linux-oem-6.0 package in Ubuntu: New Bug description: Description:KDE neon 5.26 Release:22.04 After upgrade from linux-image-6.0.0-1006-oem to linux-image-6.0.0-1007-oem I don't have sound anymore. I believe that the relevant dmesg message is this one, as it is not printed with the linux-image-6.0.0-1006-oem version: I think this bug is connected with this bub from Debian. https://lists.debian.org/debian-kernel/2022/10/msg00301.html Log: [5.535620] sof-audio-pci-intel-tgl :00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100 [5.535644] sof-audio-pci-intel-tgl :00:1f.3: Digital mics found on Skylake+ platform, using SOF driver [5.535650] sof-audio-pci-intel-tgl :00:1f.3: enabling device ( -> 0002) [5.535784] sof-audio-pci-intel-tgl :00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040100 [5.535850] sof-audio-pci-intel-tgl :00:1f.3: bound :00:02.0 (ops i915_audio_component_bind_ops [i915]) [5.544186] sof-audio-pci-intel-tgl :00:1f.3: use msi interrupt mode [5.605507] sof-audio-pci-intel-tgl :00:1f.3: hda codecs found, mask 5 [5.605509] sof-audio-pci-intel-tgl :00:1f.3: using HDA machine driver skl_hda_dsp_generic now [5.605511] sof-audio-pci-intel-tgl :00:1f.3: DMICs detected in NHLT tables: 2 [5.606867] sof-audio-pci-intel-tgl :00:1f.3: Firmware info: version 2:0:0-b678a [5.606869] sof-audio-pci-intel-tgl :00:1f.3: Firmware: ABI 3:20:0 Kernel ABI 3:23:0 [5.606872] sof-audio-pci-intel-tgl :00:1f.3: unknown sof_ext_man header type 3 size 0x30 [5.613329] iwlwifi :00:14.3: Detected RF HR B3, rfid=0x10a100 [5.679733] iwlwifi :00:14.3: base HW address: 8c:1d:96:08:c0:32 [5.691036] sof-audio-pci-intel-tgl :00:1f.3: Firmware info: version 2:0:0-b678a [5.691039] sof-audio-pci-intel-tgl :00:1f.3: Firmware: ABI 3:20:0 Kernel ABI 3:23:0 [5.695325] iwlwifi :00:14.3 wlp0s20f3: renamed from wlan0 [5.703514] sof-audio-pci-intel-tgl
[Kernel-packages] [Bug 1996678] Re: containerd sporadic timeouts
The conclusion at https://github.com/prometheus/node_exporter/issues/2500 was that the relevant kernel change that caused this was `- epoll: autoremove wakers even more aggressively`. There is a small bug reproduction script in that issue too. ** Bug watch added: github.com/prometheus/node_exporter/issues #2500 https://github.com/prometheus/node_exporter/issues/2500 -- 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/1996678 Title: containerd sporadic timeouts Status in containerd package in Ubuntu: Confirmed Status in linux package in Ubuntu: Invalid Status in containerd source package in Focal: New Status in linux source package in Focal: In Progress Bug description: This morning I routinely upgraded security upgrades on number of machines. Containerd has upgraded from `1.5.9-0ubuntu1~20.04.4` for me `1.5.9-0ubuntu1~20.04.5`. What happened next: at some random time on machines with new containerd something happens with containerd tasks and/or cgroups. This is how it's seen in syslog: containerd[710]: time="2022-11-16T03:21:21.004153517Z" level=error msg="get state for 2f5a8376b476809b1696b140ca87f91422113bb16b27a8174437cc63b48e259a" error="context deadline exceeded: unknown" And some ctr commands: # ctr --namespace k8s.io task ls|grep 2f5a8376b476809b1696b140ca87f91422113bb16b27a8174437cc63b48e259a 2f5a8376b476809b1696b140ca87f91422113bb16b27a8174437cc63b48e259a0 UNKNOWN See that the status of the task is UNKNOWN (!!!) # ctr --namespace k8s.io container ls|grep 2f5a8376b476809b1696b140ca87f91422113bb16b27a8174437cc63b48e259a 2f5a8376b476809b1696b140ca87f91422113bb16b27a8174437cc63b48e259a k8s.gcr.io/pause:3.5 io.containerd.runc.v2 Cgroups: ├─kubepods-besteffort-pod3fdc0061_bbf6_47d1_97f5_b1f271b46e23.slice │ ├─cri-containerd-5f78e0cb957de97fd8465cc42c842bdd764d981ca7a903a2515bbc6bb06796a9.scope … │ │ └─2677 /csi-node-driver-registrar --v=0 --csi-address=/csi/csi.sock --k… │ ├─cri-containerd-af070f16c1f0ff22eb16661e787e85db3810727909abd23d69a6a43578c1dced.scope … │ │ └─3264 /usr/local/bin/cephcsi --type=liveness --endpoint=unix:///csi/cs… │ ├─cri-containerd-4e063ef0c8f768dbf34cf7a179bca5cc98a04fa7e00b29d20c17d3031d409f86.scope … │ │ └─2960 /usr/local/bin/cephcsi --nodeid=nas-decent-bobcat.dev-k8s-1.hq.w… │ └─cri-containerd-2f5a8376b476809b1696b140ca87f91422113bb16b27a8174437cc63b48e259a.scope … │ └─2414 /pause # ps auxf|grep 2414 -B 2 root2279 0.1 0.0 114100 4956 ?Sl Nov15 0:42 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id 2f5a8376b476809b1696b140ca87f91422113bb16b27a8174437cc63b48e259a -address /run/containerd/containerd.sock 65535 2414 0.0 0.0964 4 ?Ss Nov15 0:00 \_ /pause It happens not immediately - but after some random time. Sometimes it's several minutes, sometimes it's around an hour. But nonetheless - all machines with the new package get into this weird state. As long as I revert package - it all returns to run as expected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/containerd/+bug/1996678/+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 1997686] 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 1997686 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/1997686 Title: Enable Intel FM350 wwan CCCI driver port logging Status in linux package in Ubuntu: Incomplete Status in linux-oem-6.0 package in Ubuntu: Invalid Status in linux source package in Jammy: Invalid Status in linux-oem-6.0 source package in Jammy: Confirmed Status in linux source package in Lunar: Incomplete Status in linux-oem-6.0 source package in Lunar: Invalid Bug description: TBD. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1997686/+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 1997686] [NEW] Enable Intel FM350 wwan CCCI driver port logging
Public bug reported: TBD. ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete ** Affects: linux-oem-6.0 (Ubuntu) Importance: Undecided Status: Invalid ** Affects: linux (Ubuntu Jammy) Importance: Undecided Status: Invalid ** Affects: linux-oem-6.0 (Ubuntu Jammy) Importance: Undecided Status: Confirmed ** Affects: linux (Ubuntu Lunar) Importance: Undecided Status: Incomplete ** Affects: linux-oem-6.0 (Ubuntu Lunar) Importance: Undecided Status: Invalid ** Also affects: linux (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Lunar) Importance: Undecided Status: New ** Also affects: linux-oem-6.0 (Ubuntu) Importance: Undecided Status: New ** Changed in: linux-oem-6.0 (Ubuntu Lunar) Status: New => Invalid ** Changed in: linux (Ubuntu Jammy) Status: New => Invalid ** Changed in: linux-oem-6.0 (Ubuntu Jammy) 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/1997686 Title: Enable Intel FM350 wwan CCCI driver port logging Status in linux package in Ubuntu: Incomplete Status in linux-oem-6.0 package in Ubuntu: Invalid Status in linux source package in Jammy: Invalid Status in linux-oem-6.0 source package in Jammy: Confirmed Status in linux source package in Lunar: Incomplete Status in linux-oem-6.0 source package in Lunar: Invalid Bug description: TBD. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1997686/+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 1970957] Re: suspend problem
Confirm issue on my Operating System: Ubuntu 22.04.1 LTS Architecture: x86-64 Hardware Vendor: Lenovo Hardware Model: ThinkPad X1 Carbon 2nd After upgrading to 5.18.11-051811-generic it seems fixed. -- 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/1970957 Title: suspend problem Status in linux package in Ubuntu: Confirmed Bug description: I've installed Ubuntu 22.04 on the ThinkPad E480. Suspend functions ok intermittently. Some times it works fine, other times the computer does not enter the suspend mode (the screen gets blank, but the machine is still running and the ThinPad led is on, and there is no way out... no response from keyboard or mouse... the only solution is to switch off manually hitting and holding the power button), other times the machine does not wakes up from suspension mode. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: ubuntu-release-upgrader-core 1:22.04.10 ProcVersionSignature: Ubuntu 5.15.0-27.28-generic 5.15.30 Uname: Linux 5.15.0-27-generic x86_64 ApportVersion: 2.20.11-0ubuntu82 Architecture: amd64 CasperMD5CheckResult: pass CrashDB: ubuntu CurrentDesktop: ubuntu:GNOME Date: Fri Apr 29 10:53:59 2022 EcryptfsInUse: Yes InstallationDate: Installed on 2022-04-24 (4 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) PackageArchitecture: all SourcePackage: ubuntu-release-upgrader Symptom: dist-upgrade UpgradeStatus: No upgrade log present (probably fresh install) --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu82 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: leoca 1913 F pulseaudio CRDA: N/A CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 22.04 EcryptfsInUse: Yes InstallationDate: Installed on 2022-04-24 (4 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) MachineType: LENOVO 20KQ000EBR Package: linux (not installed) ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-27-generic root=UUID=1e7d6212-699d-4319-b137-8a7059545433 ro quiet 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: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin lxd plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 06/14/2018 dmi.bios.release: 1.19 dmi.bios.vendor: LENOVO dmi.bios.version: R0PET42W (1.19 ) dmi.board.asset.tag: Not Available dmi.board.name: 20KQ000EBR 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.19 dmi.modalias: dmi:bvnLENOVO:bvrR0PET42W(1.19):bd06/14/2018:br1.19:efr1.19:svnLENOVO:pn20KQ000EBR:pvrThinkPadE480:rvnLENOVO:rn20KQ000EBR:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_20KQ_BU_Think_FM_ThinkPadE480: dmi.product.family: ThinkPad E480 dmi.product.name: 20KQ000EBR dmi.product.sku: LENOVO_MT_20KQ_BU_Think_FM_ThinkPad E480 dmi.product.version: ThinkPad E480 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1970957/+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 1997102] Re: illuminator control in driver sonixj
details of modification (4 program lines were modified)
modification in initialisation
static const struct usb_device_id device_table[]
...
/* {USB_DEVICE(0x06f8, 0x3008), BS(SN9C105, OV7660)}, la webcam a des LED
d'éclairage*/
{USB_DEVICE(0x06f8, 0x3008), BSF(SN9C105, OV7660, F_ILLUM)},
modification in function
static void setillum(struct gspca_dev *gspca_dev)
...
/* switch (sd->sensor) {*/
switch (sd->bridge) {
/* SN9C120 */
/* case SENSOR_ADCM1700:*/
case BRIDGE_SN9C120:
...
/* SN9C105 */
/* case SENSOR_MT9V111:*/
case BRIDGE_SN9C105:
--
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/1997102
Title:
illuminator control in driver sonixj
Status in linux package in Ubuntu:
Confirmed
Bug description:
https://packages.ubuntu.com/bionic/kernel/linux-modules-4.15.0-196-generic
file kernel/drivers/media/usb/gspca/gspca_sonixj.ko
in this driver, the illuminator est considered driven by the sensor chip.
i buyed recently an hercules (guillemot) webcam with illuminator .. 06f8:3008
the illuminator dont work.
found the sonixj.c driver source ... webcam are considered as a coupling of
two main chips
-a sensor chip with an array of photodiodes which creates the image
-a controller wich processes the image and sent the the image on the usb line
found the tech_ref of the sensor chip = NO pin to drive any led.
so, the led is driven by the controller (logic, no !)
made some modification on the sonixj.c source, build it, it works for
my webcam on an very old asus L5D (athlon 64 processor - first
generation)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1997102/+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
