[Kernel-packages] [Bug 1917272] [NEW] regression - suspend to mem stops working somewhere between 5.4.0-29.33 and 5.4.0-66.74
Public bug reported: I have one system where I use rtcwake in a cron job to have it sleep and wake up at certain times of day. I upgraded from linux- image-5.4.0-29-generic (5.4.0-29.33) to linux-image-5.4.0-66-generic (5.4.0-66.74) and the rtcwake command no longer works, failing with 'write error'. >From dmesg, the reason for this is the inability to suspend a usb device: [240303.355471] PM: dpm_run_callback(): usb_dev_suspend+0x0/0x20 returns -16 [240303.355475] PM: Device usb4 failed to suspend async: error -16 usb4 appears to be the xhci controller? # ls -l /sys/bus/usb/devices/usb4 lrwxrwxrwx 1 root root 0 Mar 1 09:36 /sys/bus/usb/devices/usb4 -> ../../../devices/pci:00/:00:14.0/usb4 # lspci -s 00:14.0 00:14.0 USB controller: Intel Corporation 9 Series Chipset Family USB xHCI Controller System is an older ASRock H97M-ITX/ac board. It does have a quirk which may be relevant - it reports what I think is every port as having an over-current condition on boot: # dmesg |grep over-current [1.083073] usb 1-1-port3: over-current condition [1.115054] usb 2-1-port5: over-current condition [1.138911] usb usb3-port7: over-current condition [1.299066] usb 1-1-port4: over-current condition [1.331053] usb 2-1-port6: over-current condition [1.354886] usb usb3-port8: over-current condition [1.570911] usb usb3-port9: over-current condition [1.786908] usb usb3-port10: over-current condition This occurs even when _no_ usb devices (or even internal cables!) are plugged into it (including removing the internal wifi/bluetooth card). It occurs on both the older (working) and newer (failing) kernel. Based on a couple of random internet posts I tried adding usbcore.autosuspend=-1 and hpet=disable to the kernel command line, but neither seemed to have any impact. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.4.0-66-generic 5.4.0-66.74 ProcVersionSignature: Ubuntu 5.4.0-66.74-generic 5.4.86 Uname: Linux 5.4.0-66-generic x86_64 AlsaVersion: Advanced Linux Sound Architecture Driver Version k5.4.0-66-generic. AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu27.16 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', '/dev/snd/controlC1', '/dev/snd/hwC1D0', '/dev/snd/pcmC1D2c', '/dev/snd/pcmC1D1p', '/dev/snd/pcmC1D0c', '/dev/snd/pcmC1D0p', '/dev/snd/controlC0', '/dev/snd/hwC0D0', '/dev/snd/pcmC0D10p', '/dev/snd/pcmC0D9p', '/dev/snd/pcmC0D8p', '/dev/snd/pcmC0D7p', '/dev/snd/pcmC0D3p', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: Card0.Amixer.info: Error: [Errno 2] No such file or directory: 'amixer' Card0.Amixer.values: Error: [Errno 2] No such file or directory: 'amixer' Card1.Amixer.info: Error: [Errno 2] No such file or directory: 'amixer' Card1.Amixer.values: Error: [Errno 2] No such file or directory: 'amixer' CasperMD5CheckResult: pass Date: Mon Mar 1 10:26:21 2021 InstallationDate: Installed on 2020-05-03 (301 days ago) InstallationMedia: Ubuntu-Server 20.04 LTS "Focal Fossa" - Release amd64 (20200423) IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' MachineType: To Be Filled By O.E.M. To Be Filled By O.E.M. ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-66-generic root=UUID=f003a362-dec7-4b1d-8208-e30812b865bc ro RelatedPackageVersions: linux-restricted-modules-5.4.0-66-generic N/A linux-backports-modules-5.4.0-66-generic N/A linux-firmware1.187.9 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 06/13/2016 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: P1.90 dmi.board.name: H97M-ITX/ac dmi.board.vendor: ASRock dmi.chassis.asset.tag: To Be Filled By O.E.M. dmi.chassis.type: 3 dmi.chassis.vendor: To Be Filled By O.E.M. dmi.chassis.version: To Be Filled By O.E.M. dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrP1.90:bd06/13/2016:svnToBeFilledByO.E.M.:pnToBeFilledByO.E.M.:pvrToBeFilledByO.E.M.:rvnASRock:rnH97M-ITX/ac:rvr:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.: dmi.product.family: To Be Filled By O.E.M. dmi.product.name: To Be Filled By O.E.M. dmi.product.sku: To Be Filled By O.E.M. dmi.product.version: To Be Filled By O.E.M. dmi.sys.vendor: To Be Filled By O.E.M. ** Affects: linux (Ubuntu) Importance: Undecided Status: Confirmed ** Tags: amd64 apport-bug focal -- 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/1917272 Title: regression - suspend to mem stops working somewhere between 5.4.0-29.33 and 5.4.0-66.74 Status in linux package in Ubuntu: Confirmed Bug
[Kernel-packages] [Bug 1893516] [NEW] On the kvm kernel, CONFIG_IP_MULTICAST is not set which breaks some apps
Public bug reported: I was trying to run minidlna in docker on a kvm VM built using the minimal image, and it wasn't working properly; eventually I tracked this down to the lack of ipv4 multicast support in the kvm kernel rendering it unable to join the SSDP multicast group (239.255.255.250). Replacing the kernel with the generic one solved the problem (which was itself non trivial because of https://bugs.launchpad.net/ubuntu/+source/linux- azure/+bug/1870189 causing the system not to load the initramfs needed by the generic kernel). Does the kernel multicast code really need to be removed for the kvm kernel? ** Affects: linux-kvm (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1893516 Title: On the kvm kernel, CONFIG_IP_MULTICAST is not set which breaks some apps Status in linux-kvm package in Ubuntu: New Bug description: I was trying to run minidlna in docker on a kvm VM built using the minimal image, and it wasn't working properly; eventually I tracked this down to the lack of ipv4 multicast support in the kvm kernel rendering it unable to join the SSDP multicast group (239.255.255.250). Replacing the kernel with the generic one solved the problem (which was itself non trivial because of https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1870189 causing the system not to load the initramfs needed by the generic kernel). Does the kernel multicast code really need to be removed for the kvm kernel? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-kvm/+bug/1893516/+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 1866149] [NEW] CONFIG_BASE_SMALL=1 restricts pid space, which conflicts with systemd default sysctl
Public bug reported: I'm not completely sure which package to log this against. I'm running the kvm focal minimal cloud image from 20200302. I noticed on boot that there was an error complaining that systemd-systemctl couldn't update pid_max to the value it wanted: systemd-sysctl[117]: Couldn't write '4194304' to 'kernel/pid_max': Invalid argument Digging into it a bit more, this comes from /usr/lib/sysctl.d/50-pid-max.conf: # Bump the numeric PID range to its maximum of 2^22 (from the in-kernel default # of 2^16), to make PID collisions less likely. kernel.pid_max = 4194304 However, the linux-image-kvm kernel is compiled with CONFIG_BASE_SMALL=1 and this triggers the following code in include/linux/threads.h #define PID_MAX_LIMIT (CONFIG_BASE_SMALL ? PAGE_SIZE * 8 : \ (sizeof(long) > 4 ? 4 * 1024 * 1024 : PID_MAX_DEFAULT)) which means that if CONFIG_BASE_SMALL is set we get a maximum limit of PAGE_SIZE * 8, which on x86 would be 32768. As a workaround I can override it with a file in /etc/sysctl.d/ but this shouldn't be needed. I really don't know if CONFIG_BASE_SMALL makes any sense on x86 cloud images, they really aren't small machines in the scheme of things! Cheers David ** Affects: linux-kvm (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1866149 Title: CONFIG_BASE_SMALL=1 restricts pid space, which conflicts with systemd default sysctl Status in linux-kvm package in Ubuntu: New Bug description: I'm not completely sure which package to log this against. I'm running the kvm focal minimal cloud image from 20200302. I noticed on boot that there was an error complaining that systemd-systemctl couldn't update pid_max to the value it wanted: systemd-sysctl[117]: Couldn't write '4194304' to 'kernel/pid_max': Invalid argument Digging into it a bit more, this comes from /usr/lib/sysctl.d/50-pid-max.conf: # Bump the numeric PID range to its maximum of 2^22 (from the in-kernel default # of 2^16), to make PID collisions less likely. kernel.pid_max = 4194304 However, the linux-image-kvm kernel is compiled with CONFIG_BASE_SMALL=1 and this triggers the following code in include/linux/threads.h #define PID_MAX_LIMIT (CONFIG_BASE_SMALL ? PAGE_SIZE * 8 : \ (sizeof(long) > 4 ? 4 * 1024 * 1024 : PID_MAX_DEFAULT)) which means that if CONFIG_BASE_SMALL is set we get a maximum limit of PAGE_SIZE * 8, which on x86 would be 32768. As a workaround I can override it with a file in /etc/sysctl.d/ but this shouldn't be needed. I really don't know if CONFIG_BASE_SMALL makes any sense on x86 cloud images, they really aren't small machines in the scheme of things! Cheers David To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-kvm/+bug/1866149/+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
