Bug#898021: linux-image-4.16.0-1-amd64: kernel 4.16 infinite wait after dm login on ivy bridge and bay trail
Am 26.07.2018 um 22:38 schrieb Lisandro Damián Nicanor Pérez Meyer: It should not. The kernel now takes more time to get the necessary entropy (actually before it was giving random values when it shouldn't). A workaround is to install haveged, but beware that some people don't trust it enough. For what I've saw having an encrypted disk helps. Regards, Lisandro I have install rng-tools5 to solve the problem. No delay with this. Holger...
Bug#898021: linux-image-4.16.0-1-amd64: kernel 4.16 infinite wait after dm login on ivy bridge and bay trail
Hi Holger! El jue., 26 de jul. de 2018 13:18, Holger Schröder escribió: > This is not really fixed in linux-image-4.17.0-1-amd64. > > I'm still having a little delay with 4.17.8-1 It should not. The kernel now takes more time to get the necessary entropy (actually before it was giving random values when it shouldn't). A workaround is to install haveged, but beware that some people don't trust it enough. For what I've saw having an encrypted disk helps. Regards, Lisandro >
Bug#898021: linux-image-4.16.0-1-amd64: kernel 4.16 infinite wait after dm login on ivy bridge and bay trail
This is not really fixed in linux-image-4.17.0-1-amd64. I'm still having a little delay with 4.17.8-1. Holger...
Bug#898021: linux-image-4.16.0-1-amd64: kernel 4.16 infinite wait after dm login on ivy bridge and bay trail
On Mon, 7 May 2018 06:40:36 +0200 "Sten Heinze" wrote:> I definitely experience a much shorter delay if I press keys on the keyboard vs. doing nothing; the delay decreases from >5 minutes to 10-20 seconds before sddm appears. Yes! I have same problem, thought not with 4.16, but with 4.17. If I login via full screen terminal, sddm starts after some seconds, without managing me to enter password second time for `sudo -i` (to check logs or whatever). Very strange bug indeed.
Bug#898021: linux-image-4.16.0-1-amd64: kernel 4.16 infinite wait after dm login on ivy bridge and bay trail
Meanwhile my Debian Testing systems have (per default) upgraded to libbsd 0.9.1 (and kernel 4.16.0-2). Unfortunaetly, this does not fix the problem (long ssdm start) under virtualization by kvm, although according to #898088 libvirt 0.9.0-1 should have alredy fixed this. On productive bare metal I cannot say anything, as I have set kernel 4.16 on hold by apt. Thx, Chris
Bug#898021: linux-image-4.16.0-1-amd64: kernel 4.16 infinite wait after dm login on ivy bridge and bay trail
Am 20.05.2018 um 16:30 schrieb Ben Hutchings: On Thu, 2018-05-17 at 18:22 +0200, Holger Schröder wrote: Any news to fix this behavior? Greetings... The bug causing (at least some) problems with starting GUIs is #898088; that's not a kernel bug. Ben. Hi. Any News? For me is this not fixed, my Intel Celereon J1900 (Bay Trail) very long Delay. Same with 4.16.0-2-amd64. With Kernel 4.15.0 no Problems. Thanks...
Bug#898021: linux-image-4.16.0-1-amd64: kernel 4.16 infinite wait after dm login on ivy bridge and bay trail
Am 20.05.2018 um 16:30 schrieb Ben Hutchings: On Thu, 2018-05-17 at 18:22 +0200, Holger Schröder wrote: Any news to fix this behavior? Greetings... The bug causing (at least some) problems with starting GUIs is #898088; that's not a kernel bug. Ben. The Patch from #898088 for me not helps, same problem (J1900 bay trail). Holger...
Bug#898021: linux-image-4.16.0-1-amd64: kernel 4.16 infinite wait after dm login on ivy bridge and bay trail
On Thu, 2018-05-17 at 18:22 +0200, Holger Schröder wrote: > Any news to fix this behavior? > > > Greetings... The bug causing (at least some) problems with starting GUIs is #898088; that's not a kernel bug. Ben. -- Ben Hutchings Horngren's Observation: Among economists, the real world is often a special case. signature.asc Description: This is a digitally signed message part
Bug#898021: linux-image-4.16.0-1-amd64: kernel 4.16 infinite wait after dm login on ivy bridge and bay trail
Any news to fix this behavior? Greetings...
Bug#898021: linux-image-4.16.0-1-amd64: kernel 4.16 infinite wait after dm login on ivy bridge and bay trail
My workarounds for this at the moment are to install tools that increase the kernel entropy pool. If not a virtual machine, and `grep -i -o -m 1 rdrand /proc/cpuinfo` returns 'rdrand', then I install the 'rng-tools5' package which uses the hardware rng in many cpu's to provide entropy to the kernel. If that fails or if it's a virtual machine, then I install the 'haveged' package. Note: Neither of these are fixes. They're work-arounds for the current issue that allow somewhat normal operation. eg; Some people have issues around how random the hardware rng is in some machines. PS: Have seen a number of people suffering this issue in #debian on freenode, and also on #debian & #debian-next on oftc. On 10 May 2018 at 15:43,wrote: > > > I can reproduce the described delay behavior on a virtualized installation > of testing using kvm after installing kernel 4.16.0-1-amd64. With > 4.15.0-3-amd64 no problem. > > Chris > > > -- Stuart Young (aka Cefiar)
Bug#898021: linux-image-4.16.0-1-amd64: kernel 4.16 infinite wait after dm login on ivy bridge and bay trail
I can reproduce the described delay behavior on a virtualized installation of testing using kvm after installing kernel 4.16.0-1-amd64. With 4.15.0-3-amd64 no problem. Chris
Bug#898021: linux-image-4.16.0-1-amd64: kernel 4.16 infinite wait after dm login on ivy bridge and bay trail
Hi Stuart, I definitely experience a much shorter delay if I press keys on the keyboard vs. doing nothing; the delay decreases from >5 minutes to 10-20 seconds before sddm appears. Sten
Bug#898021: linux-image-4.16.0-1-amd64: kernel 4.16 infinite wait after dm login on ivy bridge and bay trail
Hi Stuart, I guess it is related, just moving the mouse will indeed bypass the "freeze", but there is always some delay (4-5 sec) in which the desktop will wait. And it does happen on SSD-only laptops: a Bay Trail (Celeron) and a Ivy Bridge (i3), but not on a Pineview (Atom), this last one has a 32 bit install. Pedro
Bug#898021: linux-image-4.16.0-1-amd64: kernel 4.16 infinite wait after dm login on ivy bridge and bay trail
I'm seeing this on a few laptops with SSD's. The behaviour is that if the device isn't interacted with in any way, the machines hang for 2-4 mins at boot. Seems to be related to the fix for CVE-2018-1108 - random: fix crng_ready() test https://security-tracker.debian.org/tracker/CVE-2018-1108 Pedro & Sten, can you try introducing entropy into the systems affected when they appear to hang, to see if this reduces the delays? eg: moving the mouse, tapping shift/ctrl/alt keys, pinging the device on the network if network is already up, etc? I suspect this bug can be merged with 897599, 897632 and 897917. -- Stuart Young (aka Cefiar)
Bug#898021: linux-image-4.16.0-1-amd64: kernel 4.16 infinite wait after dm login on ivy bridge and bay trail
Package: src:linux Version: 4.16.5-1 Followup-For: Bug #898021 Dear Maintainer, I also seem to have this issue. After upgrading my kernel to linux-image-4.16.0-1-amd64, the graphical login screen (sddm) either is not shown or only shown after a delay (>10s after I complete the text mode login). Before the upgrade X would start instantly. Clicking the mouse does not seem to have an effect with my setup. Booting the previous kernel, linux-image-4.15.0-3-amd64, does not exhibit this problem. After booting linux-image-4.16.0-1-amd64, starting X from the tty (startkde in my case), works too. I can provide additional details if helpful. Sten -- Package-specific info: ** Version: Linux version 4.16.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-17)) #1 SMP Debian 4.16.5-1 (2018-04-29) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.16.0-1-amd64 root=UUID=822f5786-fcce-4563-ada9-f9c9d684742e ro quiet ** Not tainted ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: HP product_name: HP EliteBook Folio G1 product_version: chassis_vendor: HP chassis_version: bios_vendor: HP bios_version: N91 Ver. 01.16 board_vendor: HP board_name: 8170 board_version: KBC Version 29.70 ** Loaded modules: ctr ccm cmac rfcomm bnep arc4 intel_rapl nls_ascii x86_pkg_temp_thermal intel_powerclamp nls_cp437 coretemp vfat kvm_intel hid_alps fat kvm irqbypass hid_generic snd_hda_codec_hdmi crct10dif_pclmul crc32_pclmul snd_hda_codec_conexant snd_hda_codec_generic ghash_clmulni_intel intel_cstate wmi_bmof hp_wmi btusb btrtl btbcm btintel iwlmvm bluetooth mac80211 snd_soc_skl jitterentropy_rng snd_soc_skl_ipc snd_hda_ext_core iwlwifi snd_soc_sst_dsp intel_uncore snd_soc_sst_ipc snd_soc_acpi intel_rapl_perf drbg snd_soc_core efi_pstore ansi_cprng joydev uvcvideo snd_compress cfg80211 pcspkr snd_hda_intel snd_hda_codec videobuf2_vmalloc snd_hda_core videobuf2_memops evdev i915 videobuf2_v4l2 snd_hwdep ecdh_generic serio_raw videobuf2_common efivars videodev snd_pcm rfkill media crc16 idma64 snd_timer drm_kms_helper snd iTCO_wdt soundcore iTCO_vendor_support drm mei_me tpm_crb shpchp mei intel_lpss_pci intel_lpss i2c_algo_bit intel_pch_thermal wmi battery tpm_tis tpm_tis_core intel_hid tpm sparse_keymap video rng_core ac hp_wireless button acpi_pad efivarfs ip_tables x_tables autofs4 btrfs crc32c_generic xor zstd_decompress zstd_compress xxhash raid6_pq crc32c_intel nvme aesni_intel aes_x86_64 crypto_simd xhci_pci cryptd glue_helper xhci_hcd i2c_i801 psmouse nvme_core usbcore usb_common i2c_hid thermal hid ** Network interface configuration: # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback ** Network status: *** IP interfaces and addresses: 1: lo:mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: wlp109s0: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether a0:c5:89:21:5e:b2 brd ff:ff:ff:ff:ff:ff inet 192.168.0.101/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp109s0 valid_lft 85617sec preferred_lft 85617sec inet6 fe80::ec5c:f6ba:937a:f66b/64 scope link noprefixroute valid_lft forever preferred_lft forever *** Device statistics: Inter-| Receive| Transmit face |bytespackets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed lo: 48172 592000 0 0 048172 592000 0 0 0 wlp109s0: 29612796 21537000 0 0 0 721865 6479000 0 0 0 ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Skylake Host Bridge/DRAM Registers [8086:190c] (rev 08) Subsystem: Hewlett-Packard Company Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers [103c:8170] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: skl_uncore 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 515 [8086:191e] (rev 07) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company HD Graphics 515 [103c:8170] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr-
Bug#898021: linux-image-4.16.0-1-amd64: kernel 4.16 infinite wait after dm login on ivy bridge and bay trail
Package: src:linux Version: 4.16.5-1 Severity: important Dear Maintainer, kernel 4.16 on debian testing is causing an infinite wait after the FIRST display manager authentication. clicking the mouse buttons alternately L-R-L-R sometimes ceases it. subsequent authentications are good. rebooting repeats it. tested with lightdm and xdm, and xfce and lxqt. seen on yvy bridge and bay trail systems using integrated intel graphics. ok on dicrete nvidia graphics using the vendor driver, and old GMA3000 and N550 (pineview) systems. all fine when booting 4.15. -- Package-specific info: ** Version: Linux version 4.16.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-17)) #1 SMP Debian 4.16.5-1 (2018-04-29) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.16.0-1-amd64 root=UUID=5c551418-b5f0-4854-aeb4-383d6dd9d36e ro quiet ** Tainted: PWO (4609) * Proprietary module has been loaded. * Taint on warning. * Out-of-tree module has been loaded. ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: System manufacturer product_name: P5E product_version: System Version chassis_vendor: Chassis Manufacture chassis_version: Chassis Version bios_vendor: American Megatrends Inc. bios_version: 1201 board_vendor: ASUSTeK Computer INC. board_name: P5E board_version: Rev 1.xx ** Loaded modules: cpuid pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) zram zsmalloc fuse cpufreq_userspace cpufreq_powersave cpufreq_conservative binfmt_misc snd_hda_codec_analog snd_hda_codec_generic snd_hda_codec_hdmi pktcdvd joydev iTCO_wdt iTCO_vendor_support evdev coretemp kvm_intel ip6t_REJECT nf_reject_ipv6 snd_hda_intel kvm snd_hda_codec irqbypass nf_log_ipv6 snd_hda_core snd_hwdep snd_pcm serio_raw pcspkr snd_timer xt_hl sg snd lpc_ich x38_edac ip6t_rt soundcore shpchp asus_atk0110 button nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT nf_reject_ipv4 nf_log_ipv4 nf_log_common xt_LOG xt_limit xt_tcpudp xt_addrtype nf_conntrack_ipv4 nf_defrag_ipv4 nvidia_drm(PO) xt_conntrack drm_kms_helper drm ip6table_filter ip6_tables nvidia_modeset(PO) nf_conntrack_netbios_ns nf_conntrack_broadcast nf_nat_ftp nf_nat nvidia(PO) nf_conntrack_ftp nf_conntrack ipmi_devintf ipmi_msghandler parport_pc iptable_filter ppdev lp parport ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 fscrypto ecb crypto_simd cryptd glue_helper aes_x86_64 btrfs zstd_decompress zstd_compress xxhash raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sr_mod cdrom sd_mod hid_generic usbhid hid ahci libahci libata scsi_mod sky2 i2c_i801 r8169 xhci_pci mii uhci_hcd ehci_pci xhci_hcd ehci_hcd usbcore usb_common ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation 82X38/X48 Express DRAM Controller [8086:29e0] (rev 01) Subsystem: ASUSTeK Computer Inc. 82X38/X48 Express DRAM Controller [1043:8295] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: x38_edac Kernel modules: x38_edac 00:01.0 PCI bridge [0604]: Intel Corporation 82X38/X48 Express Host-Primary PCI Express Bridge [8086:29e1] (rev 01) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport Kernel modules: shpchp 00:06.0 PCI bridge [0604]: Intel Corporation 82X38/X48 Express Host-Secondary PCI Express Bridge [8086:29e9] (rev 01) (prog-if 00 [Normal decode]) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport Kernel modules: shpchp 00:1a.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. P5K PRO Motherboard [1043:8277] Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: uhci_hcd Kernel modules: uhci_hcd 00:1a.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. P5K PRO Motherboard [1043:8277] Control: I/O+ Mem-