Created attachment 1906194 [details] dmesq.txt 1. Please describe the problem: After upgrading the system to Fedora 37 (regularly updated to the latest version), the laptop started to freeze on boot up with kernel panic when being connected to a usb-c docking station. When disconnected, it boots just fine. The issue has been observed on two Lenovo laptops, such as ThinkPad T580 and ThinkPad P1 (4th gen.) 2. What is the Version-Release number of the kernel: 5.19.1-300.fc37.x86_64 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : The issue happened with this kernel on Fedora 37. Fedora 36 was doing fine. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: I can reproduce the issue when the computer has been powered off before and when I power it on and try to boot. 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: I have not tried as I need to keep my computers as close to the Beta branch as possible to be able to see any bugs that creep out. 6. Are you running any modules that not shipped with directly Fedora's kernel?: No. 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. I am attaching this, but I doubt the kernel panic info will be available in this. However, you might see some glitch.
I am also attaching several picture that I took with my mobile phone. Did not know how to capture the kernel output in a different way.
Created attachment 1906198 [details] First couple of messages
Created attachment 1906199 [details] Second part of messages
Created attachment 1906200 [details] Third part of messages
Created attachment 1906201 [details] Second panic, part 1
Created attachment 1906202 [details] Second panic, part 2
Created attachment 1906203 [details] Second panic, part 3
This is still happening even with the latest kernel 5.19.6-300.fc37.x86_64. In the logs, I was able to spot the place where an error was recorded before the computer panicked. The whole boot process is attached, but that interesting place looks like this (you can see that there is a two minute gap of nothing in the logs) ~~~ zář 02 08:19:01 fedora systemd[1]: Started systemd-ask-password-plymouth.service - Forward Password Requests to Plymouth. zář 02 08:19:01 fedora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-ask-password-plymouth comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' zář 02 08:19:01 fedora kernel: usb 6-1: new SuperSpeed USB device number 2 using xhci_hcd zář 02 08:19:01 fedora kernel: usb 6-1: New USB device found, idVendor=17ef, idProduct=3069, bcdDevice=31.03 zář 02 08:19:01 fedora kernel: usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=6 zář 02 08:19:01 fedora kernel: usb 6-1: Product: ThinkPad TBT3 LAN zář 02 08:19:01 fedora kernel: usb 6-1: Manufacturer: Lenovo zář 02 08:19:01 fedora kernel: usb 6-1: SerialNumber: 301000001 zář 02 08:19:01 fedora kernel: i915 0000:00:02.0: vgaarb: deactivate vga console zář 02 08:19:01 fedora kernel: Console: switching to colour dummy device 80x25 zář 02 08:19:01 fedora kernel: i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem zář 02 08:19:01 fedora kernel: i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4) zář 02 08:19:01 fedora kernel: usbcore: registered new interface driver r8152 zář 02 08:19:01 fedora kernel: i915 0000:00:02.0: [drm] [ENCODER:102:DDI B/PHY B] is disabled/in DSI mode with an ungated DDI clock, gate it zář 02 08:19:01 fedora kernel: i915 0000:00:02.0: [drm] [ENCODER:118:DDI C/PHY C] is disabled/in DSI mode with an ungated DDI clock, gate it zář 02 08:19:01 fedora kernel: [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0 zář 02 08:19:01 fedora kernel: ACPI: video: Video Device [GFX0] (multi-head: yes rom: no post: no) zář 02 08:19:01 fedora kernel: input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input12 zář 02 08:19:02 fedora kernel: usb 6-1: reset SuperSpeed USB device number 2 using xhci_hcd zář 02 08:19:02 fedora kernel: r8152 6-1:1.0: load rtl8153b-2 v1 10/23/19 successfully zář 02 08:19:02 fedora kernel: r8152 6-1:1.0 eth0: v1.12.13 zář 02 08:19:02 fedora kernel: fbcon: i915drmfb (fb0) is primary device zář 02 08:19:02 fedora kernel: r8152 6-1:1.0 enp14s0u1: renamed from eth0 zář 02 08:19:02 fedora kernel: scsi 0:0:0:0: Direct-Access Generic- SD/MMC 1.00 PQ: 0 ANSI: 6 zář 02 08:19:02 fedora kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0 zář 02 08:19:02 fedora kernel: sd 0:0:0:0: [sda] Media removed, stopped polling zář 02 08:19:02 fedora kernel: sd 0:0:0:0: [sda] Attached SCSI removable disk zář 02 08:19:02 fedora kernel: typec port1: bound usb7-port2 (ops connector_ops) zář 02 08:19:02 fedora kernel: typec port1: bound usb8-port2 (ops connector_ops) zář 02 08:19:03 fedora kernel: Console: switching to colour frame buffer device 240x67 zář 02 08:19:03 fedora kernel: i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device zář 02 08:19:03 fedora kernel: ucsi_acpi USBC000:00: con2: failed to register alt modes zář 02 08:19:03 fedora kernel: ucsi_acpi USBC000:00: PPM init failed (-110) ~~~
Created attachment 1909149 [details] The logs from the boot process that panicked.
Proposed as a Blocker for 37-beta by Fedora user lruzicka using the blocker tracking app because: Expected installed system boot behavior A system installed without a graphical package set must boot to a working login prompt without any unintended user intervention, and all virtual consoles intended to provide a working login prompt must do so.
What hardware is this on? Do you see it on multiple devices (if you have them available)
The log files are from the ex-company Lenovo T580 which is connected to the USB-C docking station that I have been given together with it. The computer is connected to the docking station via USBC cable (also used for power) and the docking station provides a 4k screen, a keyboard and a mouse. Another Lenovo, P1, experienced the same problems when this bug was reported. I have not tried since then, but I can check. The docking station and the setup are the same.
I have just tried to boot the P1 again and it froze on the first attempt, but it had an older kernel and also there were patches to upgrade the firmware. After I updated everything, I was able to boot normally while the computer was connected twice in a row. I will report any progress in the status quo.
I have a Lenovo T16 (AMD version) here, and haven't seen this booting connected to either USB-C dock I use with it.
(In reply to Lukas Ruzicka from comment #12) > The log files are from the ex-company Lenovo T580 which is connected to the > USB-C docking station that I have been given together with it. The computer What's the make/model of the USB-C dock?
Data point, I DO NOT see kernel panic when booting 5.19.6-300.fc37.x86_64 with USB-C dock. Hardware: - Thinkpad T480s (Intel chipset) - dock 1: Lenovo ThinkPad USB-C Dock Gen2 - dock 2: SAMSUNG ELECTRONICS CO.,LTD F32TU87x (monitor with built-in USB-C dock)
I was not able to reproduce this, kernel 5.19.6-300.fc37.x86_64, tested both USB-C and Thunderbolt 3 docks. Hardware: - Thinkpad T480s (intel) - dock 1: Lenovo ThinkPad Thunderbolt 3 Dock - dock 2: Microsoft USB-C Travel Hub
I'm not seeing a kerrnel panic with a Lenovo X1 gen9 with a Lenovo ThinkPad Thunderbolt 3 Dock gen 2 but I'm not sure a Thunderbolt dock is the same as a USB-C dock.
The issue was happening on the Thunderbolt dock. However I am not seeing this any more on 5.19.7. I hope it will stay that way :D
(In reply to Lukas Ruzicka from comment #19) > The issue was happening on the Thunderbolt dock. However I am not seeing > this any more on 5.19.7. I hope it will stay that way :D Can you be specific on the make/model of "the Thunderbolt dock", you still haven't explicitly stated what the dock is so that others can test/recreate the problem to ensure it "will stay that way". Thunderbolt and USB-C are quite different, even if appearing to use the same cable/connector, so explicit details are important.
Discussed during 2022-09-06 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2022-09-06/f37-blocker-review.2022-09-06-16.00.html . Rejected as a blocker on the basis that nobody else was able to reproduce this yet, indicating it's quite hardware specific. Accepted as an FE because if you *are* affected it's bad and likely affects live images.
(In reply to Peter Robinson from comment #20) > (In reply to Lukas Ruzicka from comment #19) > > The issue was happening on the Thunderbolt dock. However I am not seeing > > this any more on 5.19.7. I hope it will stay that way :D > > Can you be specific on the make/model of "the Thunderbolt dock", you still > haven't explicitly stated what the dock is so that others can test/recreate > the problem to ensure it "will stay that way". Thunderbolt and USB-C are > quite different, even if appearing to use the same cable/connector, so > explicit details are important. https://www.lenovo.com/gb/en/accessories-and-monitors/docking/thunderbolt-docks-universal-cable-docks/Thunderbolt-Dock-Gen-2-UK/p/40AN0135UK For example, the one in the link above.
Same problem here. If i boot my laptop with the usb c dock plugged in it just hangs after loading for a few seconds. Laptop: MSI Summit E16 Flip (Model A12UCT Alder Lake generation) USB Dock: MSI USB-C Docking Station Gen 2 Fedora 37 Beta KDE Spin Kernel: 6.0.7-301
This message is a reminder that Fedora Linux 37 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '37'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 37 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 37 entered end-of-life (EOL) status on None. Fedora Linux 37 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.