Bug#958151: linux-source-5.6: Please enable hwmon for nvme drives in the kernel config (CONFIG_NVME_HWMON)
Package: linux-source-5.6 Severity: wishlist Dear Maintainer, I just tested kernel 5.6.4 from experimental, and noticed that it doesn't enable hwmon sensors for nvme drives which have been available for some time already. I'm not sure why upstream doesn't enable it by default, but it works very well in general. Please enable CONFIG_NVME_HWMON=y to expose that to Debian build of the kernel. Thanks! -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.3 (SMP w/24 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-source-5.6 depends on: ii binutils 2.34-5 ii xz-utils 5.2.4-1+b1 Versions of packages linux-source-5.6 recommends: ii bc1.07.1-2+b2 pn bison pn flex ii gcc 4:9.2.1-3.1 ii libc6-dev [libc-dev] 2.30-4 pn linux-config-5.6 pn make Versions of packages linux-source-5.6 suggests: pn libncurses-dev | ncurses-dev pn pkg-config pn qtbase5-dev
Bug#958126: linux-image-5.5.0-2-amd64: Alt-SysRq-x no longer lifts Secure Boot restrictions
On Sat, 2020-04-18 at 23:15 +, brian m. carlson wrote: > On 2020-04-18 at 21:59:35, Ben Hutchings wrote: > > Control: tag -1 wontfix > > > > On Sat, 2020-04-18 at 18:50 +, brian m. carlson wrote: > > > Package: src:linux > > > Version: 5.5.17-1 > > > Severity: important > > > > > > By default, Debian ships kernels such that when booted with Secure Boot, > > > that a user cannot hibernate their computer. However, the combination > > > Alt-SysRq-x is documented in the wiki (which is linked to from the > > > kernel) to lift these restrictions and allow the user to hibernate. > > > > > > However, in this kernel version that does not work, and the user must > > > either disable secure boot or forego hibernation. When pressing > > > Alt-SysRq-x, the following is printed: > > > > > > sysrq: HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) > > > memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) > > > show-backtrace-all-active-cpus(l) show-memory-usage(m) > > > nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) > > > unraw(r) sync(s) show-task-states(t) unmount(u) force-fb(V) > > > show-blocked-tasks(w) dump-ftrace-buffer(z) > > [...] > > > > This was an intentional change listed in the changelog, fixing bug > > #947021. Thanks for mentioning the wiki; I'll update that to reflect > > current reality. > > It looks like Ubuntu allows people physically present to use the key > still with their proposed patch. Is there a reason that patch can't be > applied here? They tried that, then gave up. > > If you can't live with the restrictions of Secure Boot, you'll have to > > turn it off. > > Can you explain why this restriction is required in the first place? > Other operating systems use Secure Boot and allow hibernation, so it > can't be that it's an intrinsic limitation. Loading a Linux hibernation image replaces the running kernel, similarly to kexec. Other operating systems probably implement it differently. > I'd like to have the behavior where I know that my boot process hasn't > been tampered with, but I don't need to be locked out of my system or > have important features turned off. Surely that's a valid use case that > should be supported. These two features are not compatible, and until someone fixes that you'll have to choose one or the other. Ben. -- Ben Hutchings I say we take off; nuke the site from orbit. It's the only way to be sure. signature.asc Description: This is a digitally signed message part
Bug#949020: linux-image-5.5.0-rc5-amd64: Poweroff/suspend doesn't work in 5.5.0-rc5
\ Original Message On 19 Apr 2020, 00:42, Uwe Kleine-König < u...@kleine-koenig.org> wrote: @Lennert: I assume you can still reproduce the problem. Do you care to test with intel\_iommu=off and report about the result? Just to make sure you and I see the same problems? Best regards Uwe I'm afraid I can't test this anymore - due to serious i915 issues I've been building and running my own kernel packages. Currently running 5.7.0-rc1 (which is still just as broken as 5.4, 5.5 and 5.6... sigh) . I haven't seen the poweroff/suspend problem in a good while. publickey - lennert@vanalboom.org - 0x0320C886.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Bug#958126: linux-image-5.5.0-2-amd64: Alt-SysRq-x no longer lifts Secure Boot restrictions
On 2020-04-18 at 21:59:35, Ben Hutchings wrote: > Control: tag -1 wontfix > > On Sat, 2020-04-18 at 18:50 +, brian m. carlson wrote: > > Package: src:linux > > Version: 5.5.17-1 > > Severity: important > > > > By default, Debian ships kernels such that when booted with Secure Boot, > > that a user cannot hibernate their computer. However, the combination > > Alt-SysRq-x is documented in the wiki (which is linked to from the > > kernel) to lift these restrictions and allow the user to hibernate. > > > > However, in this kernel version that does not work, and the user must > > either disable secure boot or forego hibernation. When pressing > > Alt-SysRq-x, the following is printed: > > > > sysrq: HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) > > memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) > > show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) > > poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) > > show-task-states(t) unmount(u) force-fb(V) show-blocked-tasks(w) > > dump-ftrace-buffer(z) > [...] > > This was an intentional change listed in the changelog, fixing bug > #947021. Thanks for mentioning the wiki; I'll update that to reflect > current reality. It looks like Ubuntu allows people physically present to use the key still with their proposed patch. Is there a reason that patch can't be applied here? > If you can't live with the restrictions of Secure Boot, you'll have to > turn it off. Can you explain why this restriction is required in the first place? Other operating systems use Secure Boot and allow hibernation, so it can't be that it's an intrinsic limitation. I'd like to have the behavior where I know that my boot process hasn't been tampered with, but I don't need to be locked out of my system or have important features turned off. Surely that's a valid use case that should be supported. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#958065: linux: switch from linux-image-5.5.0-1-amd64-unsigned to linux-image-5.5.0-1-amd64 made modules being lost
On Sat, 2020-04-18 at 22:54 +0100, Ben Hutchings wrote: > No, it does not. It removes kmod's index files I probably should have better checked the code I've copy ^^ > This is a known bug but I don't know how to fix it. Maybe I'm thinking way to simple... but if depmod fixes that... couldn't one install e.g. a trigger, that runs it in the end? Or alternatively, simply call depmod unconditonally in the postrm, after the files were (potentially) removed? Maybe one could even check in e.g. the postrm of the -unsigned whether the -signed version of the same name is now installed and only invoke depmod then (and vice versa for the postrm of the -signed version). Cheers, Chris.
Bug#949020: linux-image-5.5.0-rc5-amd64: Poweroff/suspend doesn't work in 5.5.0-rc5
Hello, On Sat, Apr 18, 2020 at 03:18:35PM +0200, Uwe Kleine-König wrote: > On Sat, Apr 18, 2020 at 01:22:26PM +0200, Uwe Kleine-König wrote: > > On Fri, Apr 17, 2020 at 11:15:28AM +0200, Uwe Kleine-König wrote: > > > Control: found -1 5.5.13-2 > > > > > > On Thu, Jan 16, 2020 at 08:39:44AM +0100, Lennert Van Alboom wrote: > > > > Package: src:linux > > > > Version: 5.5~rc5-1~exp1 > > > > Severity: normal > > > > > > > > Neither shutdown nor suspend works in this kernel version. Systemd seems > > > > to indicate it is trying at least, but the system hangs either right > > > > before shutdown (clean situation, requiring a poweroff with the power > > > > button) or before sleep (hung system, can't do anything except also hard > > > > powering off and rebooting later). > > > > > > > > Syslog from a suspend action: > > > > > > > > Jan 16 06:43:53 Nesbitt NetworkManager[749]: [1579153433.6342] > > > > manager: sleep: sleep requested (sleeping: no enabled: yes) > > > > Jan 16 06:43:53 Nesbitt NetworkManager[749]: [1579153433.6343] > > > > device (p2p-dev-wlan0): state change: disconnected -> unmanaged (reason > > > > 'sleeping', sys-iface-state: 'managed') > > > > Jan 16 06:43:53 Nesbitt NetworkManager[749]: [1579153433.6345] > > > > manager: NetworkManager state is now ASLEEP > > > > Jan 16 06:43:53 Nesbitt systemd[1]: Reached target Sleep. > > > > Jan 16 06:43:53 Nesbitt systemd[1]: Starting Suspend... > > > > Jan 16 06:43:53 Nesbitt kernel: [55203.294410] PM: suspend entry > > > > (s2idle) > > > > Jan 16 06:43:53 Nesbitt systemd-sleep[19110]: Suspending system... > > > > > > I have the same problem with 5.5.13-2 on a Lenovo Thinkpad T460p, with > > > 4.19 from buster there is no such problem. I didn't debug any further > > > yet. > > > > I just reconfirmed: linux-image-4.19.0-8-amd64 4.19.98-1 doesn't suffer > > from this problem, but linux-image-5.6.0-trunk-amd64-unsigned > > 5.6.4-1~exp1 has the same problem. > > I started bisecting (but didn't complete yet, the weather is too good to > sit inside :-). Currently I see > > bad: 5.2.17-1+b1 > good: 5.2.6-1 > I checked the remaining versions in between the two above and the bisect result is that 5.2.7-1 is the last good; and 5.2.9-1 is the first bad kernel image. The relevant change between these two is: * [x86] iommu: Enable INTEL_IOMMU_DEFAULT_ON (Closes: #934309) . At least 5.2.7-1 shows the problematic behaviour when I add "intel_iommu=on" on the kernel command line. I suspect I can boot newer kernels with "intel_iommu=off", but didn't try that yet. Related: https://bugzilla.kernel.org/show_bug.cgi?id=197029 @Lennert: I assume you can still reproduce the problem. Do you care to test with intel_iommu=off and report about the result? Just to make sure you and I see the same problems? Best regards Uwe signature.asc Description: PGP signature
Processed: Re: Bug#958126: linux-image-5.5.0-2-amd64: Alt-SysRq-x no longer lifts Secure Boot restrictions
Processing control commands: > tag -1 wontfix Bug #958126 [src:linux] linux-image-5.5.0-2-amd64: Alt-SysRq-x no longer lifts Secure Boot restrictions Added tag(s) wontfix. -- 958126: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958126 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#958126: linux-image-5.5.0-2-amd64: Alt-SysRq-x no longer lifts Secure Boot restrictions
Control: tag -1 wontfix On Sat, 2020-04-18 at 18:50 +, brian m. carlson wrote: > Package: src:linux > Version: 5.5.17-1 > Severity: important > > By default, Debian ships kernels such that when booted with Secure Boot, > that a user cannot hibernate their computer. However, the combination > Alt-SysRq-x is documented in the wiki (which is linked to from the > kernel) to lift these restrictions and allow the user to hibernate. > > However, in this kernel version that does not work, and the user must > either disable secure boot or forego hibernation. When pressing > Alt-SysRq-x, the following is printed: > > sysrq: HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) > memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) > show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) > poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) > show-task-states(t) unmount(u) force-fb(V) show-blocked-tasks(w) > dump-ftrace-buffer(z) [...] This was an intentional change listed in the changelog, fixing bug #947021. Thanks for mentioning the wiki; I'll update that to reflect current reality. If you can't live with the restrictions of Secure Boot, you'll have to turn it off. Ben. -- Ben Hutchings If more than one person is responsible for a bug, no one is at fault. signature.asc Description: This is a digitally signed message part
Bug#958065: linux: switch from linux-image-5.5.0-1-amd64-unsigned to linux-image-5.5.0-1-amd64 made modules being lost
Control: forcmerge -1 #851695 On Sat, 2020-04-18 at 02:35 +0200, Christoph Anton Mitterer wrote: > Source: linux > Version: 5.5.17-1 > Severity: important > > > Hi. > > I've just switched from the linux-image-5.5.0-1-amd64-unsigned to > linux-image-5.5.0-1-amd64 > (which wasn't available as soon as the -unsigned version) in on go via apt. > > > The consequence was, that many modules were missing. I don't think so. [...] > Looking at the postrm: > if [ "$1" = purge ]; then > for extra_file in modules.dep modules.isapnpmap modules.pcimap \ > modules.usbmap modules.parportmap \ > modules.generic_string modules.ieee1394map \ > modules.ieee1394map modules.pnpbiosmap \ > modules.alias modules.ccwmap modules.inputmap \ > modules.symbols modules.ofmap \ > modules.seriomap modules.\*.bin \ > modules.softdep modules.devname; do > eval rm -f /lib/modules/$version/$extra_file > done > rmdir /lib/modules/$version || true > fi > > > It deletes all modules... which are however already belonging to the > signed version of the package. [...] No, it does not. It removes kmod's index files, after which modprobe and udev won't be able to find modules. (But any modules loaded by the initramfs will be unaffected.) Running "depmod" will fix that. This is a known bug but I don't know how to fix it. Ben. -- Ben Hutchings If more than one person is responsible for a bug, no one is at fault. signature.asc Description: This is a digitally signed message part
Bug#958126: linux-image-5.5.0-2-amd64: Alt-SysRq-x no longer lifts Secure Boot restrictions
Package: src:linux Version: 5.5.17-1 Severity: important By default, Debian ships kernels such that when booted with Secure Boot, that a user cannot hibernate their computer. However, the combination Alt-SysRq-x is documented in the wiki (which is linked to from the kernel) to lift these restrictions and allow the user to hibernate. However, in this kernel version that does not work, and the user must either disable secure boot or forego hibernation. When pressing Alt-SysRq-x, the following is printed: sysrq: HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) show-task-states(t) unmount(u) force-fb(V) show-blocked-tasks(w) dump-ftrace-buffer(z) Other relevant messages from the kernel log: Lockdown: systemd-logind: hibernation is restricted; see https://wiki.debian.org/SecureBoot Lockdown: systemd-logind: hibernation is restricted; see https://wiki.debian.org/SecureBoot Please either drop the restriction on hibernation or restore Alt-SysRq-x to its former functionality. I would like to point out that this isn't the first time that Alt-SysRq-x has broken, so if you're going to retain it, perhaps it should be part of a suitable testsuite or testing procedure before shipping a new kernel. Thanks. -- Package-specific info: ** Version: Linux version 5.5.0-2-amd64 (debian-kernel@lists.debian.org) (gcc version 9.3.0 (Debian 9.3.0-10)) #1 SMP Debian 5.5.17-1 (2020-04-15) ** Command line: BOOT_IMAGE=/vmlinuz-5.5.0-2-amd64 root=/dev/mapper/camp-root ro sysrq_always_enabled=1 processor.ignore_ppc=1 processor.ignore_tpc=1 quiet sysrq_always_enabled=1 ** Not tainted ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: LENOVO product_name: 20QDCT01WW product_version: ThinkPad chassis_vendor: LENOVO chassis_version: None bios_vendor: LENOVO bios_version: N2HET30W (1.13 ) board_vendor: LENOVO board_name: 20QDCT01WW board_version: SDK0K17763 WIN ** Loaded modules: hidp xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo nft_counter xt_addrtype nft_compat nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink br_netfilter bridge stp llc overlay ctr ccm cmac bnep snd_soc_hdac_hdmi snd_soc_dmic snd_hda_codec_realtek mei_wdt intel_rapl_msr snd_hda_codec_generic snd_sof_pci snd_sof_intel_hda_common snd_sof_intel_hda snd_sof_intel_byt snd_sof_intel_ipc snd_sof snd_sof_xtensa_dsp snd_soc_skl snd_soc_hdac_hda snd_hda_ext_core snd_soc_sst_ipc btusb snd_soc_sst_dsp x86_pkg_temp_thermal btrtl intel_powerclamp snd_soc_acpi_intel_match btbcm coretemp snd_soc_acpi btintel kvm_intel iwlmvm efi_pstore kvm binfmt_misc irqbypass mac80211 snd_soc_core bluetooth intel_cstate snd_compress snd_hda_intel snd_intel_dspcfg nls_ascii intel_uncore nls_cp437 intel_rapl_perf snd_usb_audio snd_hda_codec libarc4 vfat serio_raw fat pcspkr snd_usbmidi_lib snd_hda_core snd_rawmidi efivars uvcvideo snd_seq_device iTCO_wdt snd_hwdep videobuf2_vmalloc videobuf2_memops iTCO_vendor_support wmi_bmof intel_wmi_thunderbolt watchdog iwlwifi snd_pcm sg videobuf2_v4l2 processor_thermal_device drbg videobuf2_common tpm_crb snd_timer hid_sensor_gyro_3d mei_me hid_sensor_accel_3d intel_rapl_common videodev ansi_cprng thinkpad_acpi hid_sensor_trigger tpm_tis hid_sensor_iio_common tpm_tis_core ucsi_acpi industrialio_triggered_buffer ecdh_generic cfg80211 mc kfifo_buf typec_ucsi mei ecc tpm industrialio intel_soc_dts_iosf nvram intel_pch_thermal typec ledtrig_audio rng_core snd soundcore rfkill int3403_thermal ac int340x_thermal_zone evdev int3400_thermal acpi_thermal_rel acpi_pad acpi_tad parport_pc ppdev lp parport efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic btrfs zstd_decompress zstd_compress dm_crypt dm_mod raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor hid_sensor_custom raid6_pq hid_sensor_hub libcrc32c raid1 raid0 multipath linear md_mod intel_ishtp_hid sd_mod hid_generic usbhid hid uas usb_storage scsi_mod crct10dif_pclmul crc32_pclmul crc32c_intel i915 ghash_clmulni_intel aesni_intel i2c_designware_platform i2c_designware_core crypto_simd e1000e psmouse cryptd glue_helper i2c_i801 drm_kms_helper xhci_pci xhci_hcd igb dca ptp drm pps_core i2c_algo_bit usbcore thunderbolt nvme nvme_core intel_ish_ipc intel_lpss_pci intel_ishtp intel_lpss idma64 mfd_core usb_common wmi battery video button ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Coffee Lake HOST and DRAM Controller [8086:3e34] (rev 0c) Subsystem: Lenovo Coffee Lake HOST and DRAM Controller [17aa:2292] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr-
Bug#949020: linux-image-5.5.0-rc5-amd64: Poweroff/suspend doesn't work in 5.5.0-rc5
hello, On Sat, Apr 18, 2020 at 01:22:26PM +0200, Uwe Kleine-König wrote: > On Fri, Apr 17, 2020 at 11:15:28AM +0200, Uwe Kleine-König wrote: > > Control: found -1 5.5.13-2 > > > > On Thu, Jan 16, 2020 at 08:39:44AM +0100, Lennert Van Alboom wrote: > > > Package: src:linux > > > Version: 5.5~rc5-1~exp1 > > > Severity: normal > > > > > > Neither shutdown nor suspend works in this kernel version. Systemd seems > > > to indicate it is trying at least, but the system hangs either right > > > before shutdown (clean situation, requiring a poweroff with the power > > > button) or before sleep (hung system, can't do anything except also hard > > > powering off and rebooting later). > > > > > > Syslog from a suspend action: > > > > > > Jan 16 06:43:53 Nesbitt NetworkManager[749]: [1579153433.6342] > > > manager: sleep: sleep requested (sleeping: no enabled: yes) > > > Jan 16 06:43:53 Nesbitt NetworkManager[749]: [1579153433.6343] > > > device (p2p-dev-wlan0): state change: disconnected -> unmanaged (reason > > > 'sleeping', sys-iface-state: 'managed') > > > Jan 16 06:43:53 Nesbitt NetworkManager[749]: [1579153433.6345] > > > manager: NetworkManager state is now ASLEEP > > > Jan 16 06:43:53 Nesbitt systemd[1]: Reached target Sleep. > > > Jan 16 06:43:53 Nesbitt systemd[1]: Starting Suspend... > > > Jan 16 06:43:53 Nesbitt kernel: [55203.294410] PM: suspend entry (s2idle) > > > Jan 16 06:43:53 Nesbitt systemd-sleep[19110]: Suspending system... > > > > I have the same problem with 5.5.13-2 on a Lenovo Thinkpad T460p, with > > 4.19 from buster there is no such problem. I didn't debug any further > > yet. > > I just reconfirmed: linux-image-4.19.0-8-amd64 4.19.98-1 doesn't suffer > from this problem, but linux-image-5.6.0-trunk-amd64-unsigned > 5.6.4-1~exp1 has the same problem. I started bisecting (but didn't complete yet, the weather is too good to sit inside :-). Currently I see bad: 5.2.17-1+b1 good: 5.2.6-1 So this is either a regression (also) in stable or something Debian-specific (or I did something wrong). Best regards Uwe signature.asc Description: PGP signature
Bug#949020: linux-image-5.5.0-rc5-amd64: Poweroff/suspend doesn't work in 5.5.0-rc5
Hello again, On Fri, Apr 17, 2020 at 11:15:28AM +0200, Uwe Kleine-König wrote: > Control: found -1 5.5.13-2 > > On Thu, Jan 16, 2020 at 08:39:44AM +0100, Lennert Van Alboom wrote: > > Package: src:linux > > Version: 5.5~rc5-1~exp1 > > Severity: normal > > > > Neither shutdown nor suspend works in this kernel version. Systemd seems > > to indicate it is trying at least, but the system hangs either right > > before shutdown (clean situation, requiring a poweroff with the power > > button) or before sleep (hung system, can't do anything except also hard > > powering off and rebooting later). > > > > Syslog from a suspend action: > > > > Jan 16 06:43:53 Nesbitt NetworkManager[749]: [1579153433.6342] > > manager: sleep: sleep requested (sleeping: no enabled: yes) > > Jan 16 06:43:53 Nesbitt NetworkManager[749]: [1579153433.6343] > > device (p2p-dev-wlan0): state change: disconnected -> unmanaged (reason > > 'sleeping', sys-iface-state: 'managed') > > Jan 16 06:43:53 Nesbitt NetworkManager[749]: [1579153433.6345] > > manager: NetworkManager state is now ASLEEP > > Jan 16 06:43:53 Nesbitt systemd[1]: Reached target Sleep. > > Jan 16 06:43:53 Nesbitt systemd[1]: Starting Suspend... > > Jan 16 06:43:53 Nesbitt kernel: [55203.294410] PM: suspend entry (s2idle) > > Jan 16 06:43:53 Nesbitt systemd-sleep[19110]: Suspending system... > > I have the same problem with 5.5.13-2 on a Lenovo Thinkpad T460p, with > 4.19 from buster there is no such problem. I didn't debug any further > yet. I just reconfirmed: linux-image-4.19.0-8-amd64 4.19.98-1 doesn't suffer from this problem, but linux-image-5.6.0-trunk-amd64-unsigned 5.6.4-1~exp1 has the same problem. On thing I noticed: When I send my Laptop in suspend, the power LED starts blinking slowly (as it does with 4.19), but the FnLk LED stays on which on 4.19 goes off shortly after suspend is reached. So I think the problem is in the going to sleep step, not only when (not) waking up. Best regards Uwe signature.asc Description: PGP signature
linux-image-5.6.0-trunk-amd64-unsigned: Please enable CONFIG_VBOXSF_FS as module
Hi, can you please enable CONFIG_VBOXSF_FS as module? $ grep VBOX /boot/config-5.6.0-trunk-amd64 CONFIG_DRM_VBOXVIDEO=m CONFIG_VBOXGUEST=m # CONFIG_VBOXSF_FS is not set Not sure if virtualbox-guest-* like virtualbox-guest-dkms Debian packages are then co-installable and co-usable. Thanks. Regards, - Sedat - [1] https://cateee.net/lkddb/web-lkddb/VBOXSF_FS.html
diffconfig: config-5.5.0-2-amd64 VS. config-5.6.0-trunk-amd64
[ Please CC me I am not subscribed to this ML ] Hi, I installed linux-image-5.6.0-trunk-amd64-unsigned (5.6.4-1~exp1). When I compare the Kconfig changes between linux-image-5.5.0-2-amd64 (5.5.17-1) with above I see this diff: $ cd /path/to/linux $ scripts/diffconfig /boot/config-5.5.0-2-amd64 /boot/config-5.6.0-trunk-amd64 | grep ' -> ' BATMAN_ADV_SYSFS y -> n BUILD_SALT "5.5.0-2-amd64" -> "5.6.0-trunk-amd64" CEC_CORE y -> m CRC_T10DIF y -> m CRYPTO_AES y -> m CRYPTO_CBC y -> m CRYPTO_CRCT10DIF y -> m CRYPTO_CTS y -> m CRYPTO_ECB y -> m CRYPTO_LIB_AES y -> m CRYPTO_SHA512 y -> m CRYPTO_XTS y -> m ISDN_CAPI m -> y RESET_ATTACK_MITIGATION n -> y SND_HDA_PREALLOC_SIZE 2048 -> 0 SND_SOC_SOF_HDA_COMMON_HDMI_CODEC n -> y Not sure if this was intended and one of the Kconfigs is relevant for booting. Please check and let me know. Thanks. Regards, - Sedat -
Bug#956802: linux-image-5.5.0-1-amd64: System fails to suspend due to a problem with the e1000e driver
Good news, it looks like the problem was solved in 5.5.0-2. Now the system suspends correctly. Am Mittwoch, den 15.04.2020, 14:10 +0200 schrieb Erik Tews: > Package: src:linux > Version: 5.5.13-2 > Severity: normal > > I have a Thinkpad X1 Yoga 4th gen and it fails to suspend. In dmesg, > I can see > some messages that look like the problem is related to the e1000e > driver. My > laptop doesn't have a physical Ethernet port, but it can be added > using an > adaptor or a docking station. At the time when I tried that, no > Ethernet > adaptor was present. > > Removing the kernel module with "rmmod e1000e" solves the issue, the > laptop > suspends perfectly fine, but of course no wired networking is > available. The > system worked fine with the latest 5.4 kernel from Debian, so I > assume the > problem must have been introduced with the 5.4 to 5.5 upgrade. > > > > -- Package-specific info: > ** Version: > Linux version 5.5.0-1-amd64 (debian-kernel@lists.debian.org) (gcc > version 9.3.0 (Debian 9.3.0-8)) #1 SMP Debian 5.5.13-2 (2020-03-30) > > ** Command line: > BOOT_IMAGE=/vmlinuz-5.5.0-1-amd64 root=/dev/mapper/yogi-root ro quiet > snd_hda_intel.dmic_detect=0 > > ** Tainted: W (512) > * kernel issued warning > > ** Kernel log: > [245510.575811] usb 5-2.1.1.4: SerialNumber: > [245510.616462] usb 5-2.1.3: new low-speed USB device number 8 using > xhci_hcd > [245510.730708] input: Lenovo ThinkPad Thunderbolt 3 Dock USB Audio > as > /devices/pci:00/:00:1d.4/:05:00.0/:06:01.0/:08:00 > .0/:09:02.0/:0a:00.0/usb5/5-2/5-2.1/5-2.1.1/5-2.1.1.4/5- > 2.1.1.4:1.3/0003:17EF:3083.0018/input/input67 > [245510.780188] usb 5-2.1.3: New USB device found, idVendor=046a, > idProduct=0023, bcdDevice= 2.20 > [245510.780194] usb 5-2.1.3: New USB device strings: Mfr=0, > Product=0, SerialNumber=0 > [245510.792766] hid-generic 0003:17EF:3083.0018: input,hidraw3: USB > HID v1.11 Device [Lenovo ThinkPad Thunderbolt 3 Dock USB Audio] on > usb-:0a:00.0-2.1.1.4/input3 > [245510.799680] input: HID 046a:0023 as > /devices/pci:00/:00:1d.4/:05:00.0/:06:01.0/:08:00 > .0/:09:02.0/:0a:00.0/usb5/5-2/5-2.1/5-2.1.3/5- > 2.1.3:1.0/0003:046A:0023.0019/input/input68 > [245510.849102] usb 6-2.1.2: reset SuperSpeedPlus Gen 2 USB device > number 5 using xhci_hcd > [245510.857320] cherry 0003:046A:0023.0019: input,hidraw4: USB HID > v1.11 Keyboard [HID 046a:0023] on usb-:0a:00.0-2.1.3/input0 > [245510.865632] input: HID 046a:0023 as > /devices/pci:00/:00:1d.4/:05:00.0/:06:01.0/:08:00 > .0/:09:02.0/:0a:00.0/usb5/5-2/5-2.1/5-2.1.3/5- > 2.1.3:1.1/0003:046A:0023.001A/input/input69 > [245510.874054] r8152 6-2.1.2:1.0 (unnamed net_device) > (uninitialized): Invalid header when reading pass-thru MAC addr > [245510.874136] r8152 6-2.1.2:1.0: firmware: failed to load > rtl_nic/rtl8153b-2.fw (-2) > [245510.874144] r8152 6-2.1.2:1.0: Direct firmware load for > rtl_nic/rtl8153b-2.fw failed with error -2 > [245510.874149] r8152 6-2.1.2:1.0: unable to load firmware patch > rtl_nic/rtl8153b-2.fw (-2) > [245510.919509] r8152 6-2.1.2:1.0 eth0: v1.11.11 > [245510.928796] cherry 0003:046A:0023.001A: input,hidraw5: USB HID > v1.11 Device [HID 046a:0023] on usb-:0a:00.0-2.1.3/input1 > [245510.990713] r8152 6-2.1.2:1.0 enx3ce1a14ecc73: renamed from eth0 > [245511.060503] usb 5-2.1.4: new full-speed USB device number 9 using > xhci_hcd > [245511.212673] usb 5-2.1.4: New USB device found, idVendor=046d, > idProduct=c07e, bcdDevice=90.03 > [245511.212680] usb 5-2.1.4: New USB device strings: Mfr=1, > Product=2, SerialNumber=3 > [245511.212684] usb 5-2.1.4: Product: Gaming Mouse G402 > [245511.212688] usb 5-2.1.4: Manufacturer: Logitech > [245511.212690] usb 5-2.1.4: SerialNumber: 6D77589C5255 > [245511.223820] input: Logitech Gaming Mouse G402 as > /devices/pci:00/:00:1d.4/:05:00.0/:06:01.0/:08:00 > .0/:09:02.0/:0a:00.0/usb5/5-2/5-2.1/5-2.1.4/5- > 2.1.4:1.0/0003:046D:C07E.001B/input/input70 > [245511.224476] hid-generic 0003:046D:C07E.001B: input,hidraw6: USB > HID v1.11 Mouse [Logitech Gaming Mouse G402] on usb-:0a:00.0- > 2.1.4/input0 > [245511.227020] input: Logitech Gaming Mouse G402 Keyboard as > /devices/pci:00/:00:1d.4/:05:00.0/:06:01.0/:08:00 > .0/:09:02.0/:0a:00.0/usb5/5-2/5-2.1/5-2.1.4/5- > 2.1.4:1.1/0003:046D:C07E.001C/input/input71 > [245511.285057] input: Logitech Gaming Mouse G402 Consumer Control as > /devices/pci:00/:00:1d.4/:05:00.0/:06:01.0/:08:00 > .0/:09:02.0/:0a:00.0/usb5/5-2/5-2.1/5-2.1.4/5- > 2.1.4:1.1/0003:046D:C07E.001C/input/input72 > [245511.285459] input: Logitech Gaming Mouse G402 System Control as > /devices/pci:00/:00:1d.4/:05:00.0/:06:01.0/:08:00 > .0/:09:02.0/:0a:00.0/usb5/5-2/5-2.1/5-2.1.4/5- > 2.1.4:1.1/0003:046D:C07E.001C/input/input73 > [245511.286010] hid-generic 0003:046D:C07E.001C: > input,hiddev0,hidraw7: USB
