Isn’t this an SDDM bug at this point then?
Well, the entire system hangs until I open the screen and replug the usb-c to the dock.
So, don’t know really :}
When the “hang” happens, can you SSH into it from another machine? Or is it totally frozen? If it’s not totally frozen, can you capture the journal at that specific moment? Maybe there is something in the journal showing what SDDM is doing. If not, maybe you can put SDDM into a verbose or debug mode for hints.
I’ll try that. Will let you know what comes out of it.
Note that the power-on comes from BIOS trigger → Power detect == Power on.
For @Mario_Limonciello - so - it seems something is stuck when powering on automatically:
- Laptop is in its stand (lid closed).
- BIOS configuration: (Power on when power applied) and you apply power (Power the dock).
- Boot process will start. I am able to provide password (blind) to unlock the /home drive
- nothing happens.
This is where (4.) I try to remote log in. Not possible Not even ping replies, and ARP table on my router is empty.
I have to literrally unplug the USB-C form the laptop (Dock ↔ Laptop), wait 5 seconds, plug it in again, and open the lid for the system to continue to boot.
Note that the “Turn off screen” whil on power is active.
Once I’m logged in, I can access the device also through network. Guess the Network manager needs to be active for network to be enabled.
Any more hint?
I think we have to look at a journal from that boot for hints. Can you please describe with timestamps in your journal which actions were when? Maybe we’ll get a sense of what’s actually happening.
My current hypothesis is SDDM is failing to startup properly with the display closed because it has nothing to render to.
Let me ask this - what happens with lid opened and dock connected at boot? Does that actually work? And dock keeps working?
When I let the system boot while the screen/lid is open and I apply power, it works as expected.
If the laptop is closed and I apply power, it boots, but no external screen.
Still having a warning about the DP though (latest kernel → 6.10.7-061007-generic)
août 30 12:40:43 jupiter.solsys.org kernel: ------------[ cut here ]------------
août 30 12:40:43 jupiter.solsys.org kernel: WARNING: CPU: 11 PID: 241 at drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability>
août 30 12:40:43 jupiter.solsys.org kernel: Modules linked in: cdc_ncm cdc_ether usbnet r8152 mii usbhid amdgpu(+) amdxcp drm_exec gpu_sched drm_bu>
août 30 12:40:43 jupiter.solsys.org kernel: CPU: 11 PID: 241 Comm: systemd-udevd Tainted: G W 6.10.7-061007-generic #202408291638
août 30 12:40:43 jupiter.solsys.org kernel: Hardware name: Framework Laptop 16 (AMD Ryzen 7040 Series)/FRANMZCP07, BIOS 03.04 07/09/2024
août 30 12:40:43 jupiter.solsys.org kernel: RIP: 0010:dp_retrieve_lttpr_cap+0x13b/0x210 [amdgpu]
août 30 12:40:43 jupiter.solsys.org kernel: Code: c1 e2 38 48 09 d0 49 89 84 24 98 02 00 00 41 f6 84 24 c4 02 00 00 02 74 45 e8 b1 e7 ff ff 84 c0 7>
août 30 12:40:43 jupiter.solsys.org kernel: RSP: 0018:ffffae0d4088f1d8 EFLAGS: 00010246
août 30 12:40:43 jupiter.solsys.org kernel: RAX: ffff9eab6d3c6700 RBX: 00000000ffffffff RCX: 00ffffffffffffff
août 30 12:40:43 jupiter.solsys.org kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
août 30 12:40:43 jupiter.solsys.org kernel: RBP: ffffae0d4088f200 R08: 0000000000000000 R09: 0000000000000000
août 30 12:40:43 jupiter.solsys.org kernel: R10: 0000000000000000 R11: 0000000000000000 R12: ffff9eab6d31b800
août 30 12:40:43 jupiter.solsys.org kernel: R13: ffffae0d4088f324 R14: ffff9eab7b000000 R15: ffff9eab6d31b800
août 30 12:40:43 jupiter.solsys.org kernel: FS: 00007697b2ee98c0(0000) GS:ffff9eb9a1f80000(0000) knlGS:0000000000000000
août 30 12:40:43 jupiter.solsys.org kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
août 30 12:40:43 jupiter.solsys.org kernel: CR2: 0000631258bbb438 CR3: 0000000124aae000 CR4: 0000000000f50ef0
août 30 12:40:43 jupiter.solsys.org kernel: PKRU: 55555554
août 30 12:40:43 jupiter.solsys.org kernel: Call Trace:
août 30 12:40:43 jupiter.solsys.org kernel: <TASK>
août 30 12:40:43 jupiter.solsys.org kernel: ? srso_alias_return_thunk+0x5/0xfbef5
août 30 12:40:43 jupiter.solsys.org kernel: ? show_trace_log_lvl+0x273/0x310
août 30 12:40:43 jupiter.solsys.org kernel: ? show_trace_log_lvl+0x273/0x310
août 30 12:40:43 jupiter.solsys.org kernel: ? retrieve_link_cap+0x79/0xd80 [amdgpu]
août 30 12:40:43 jupiter.solsys.org kernel: ? show_regs.part.0+0x22/0x30
août 30 12:40:43 jupiter.solsys.org kernel: ? show_regs.cold+0x8/0x10
août 30 12:40:43 jupiter.solsys.org kernel: ? dp_retrieve_lttpr_cap+0x13b/0x210 [amdgpu]
août 30 12:40:43 jupiter.solsys.org kernel: ? __warn.cold+0xa7/0x101
août 30 12:40:43 jupiter.solsys.org kernel: ? dp_retrieve_lttpr_cap+0x13b/0x210 [amdgpu]
août 30 12:40:43 jupiter.solsys.org kernel: ? report_bug+0x114/0x160
août 30 12:40:43 jupiter.solsys.org kernel: ? handle_bug+0x51/0xa0
août 30 12:40:43 jupiter.solsys.org kernel: ? exc_invalid_op+0x18/0x80
août 30 12:40:43 jupiter.solsys.org kernel: ? asm_exc_invalid_op+0x1b/0x20
août 30 12:40:43 jupiter.solsys.org kernel: ? dp_retrieve_lttpr_cap+0x13b/0x210 [amdgpu]
août 30 12:40:43 jupiter.solsys.org kernel: ? dp_retrieve_lttpr_cap+0x12f/0x210 [amdgpu]
août 30 12:40:43 jupiter.solsys.org kernel: retrieve_link_cap+0x79/0xd80 [amdgpu]
août 30 12:40:43 jupiter.solsys.org kernel: ? srso_alias_return_thunk+0x5/0xfbef5
août 30 12:40:43 jupiter.solsys.org kernel: ? dm_helpers_is_dp_sink_present+0x3d/0x50 [amdgpu]
août 30 12:40:43 jupiter.solsys.org kernel: detect_dp_sink_caps+0xe/0x20 [amdgpu]
août 30 12:40:43 jupiter.solsys.org kernel: detect_dp+0x78/0x1b0 [amdgpu]
août 30 12:40:43 jupiter.solsys.org kernel: detect_link_and_local_sink+0x7b7/0xc20 [amdgpu]
août 30 12:40:43 jupiter.solsys.org kernel: ? amdgpu_cgs_write_register+0x14/0x30 [amdgpu]
août 30 12:40:43 jupiter.solsys.org kernel: link_detect+0x1f/0x2e0 [amdgpu]
août 30 12:40:43 jupiter.solsys.org kernel: dc_link_detect+0x1d/0x30 [amdgpu]
août 30 12:40:43 jupiter.solsys.org kernel: amdgpu_dm_initialize_drm_device+0x5bd/0xb20 [amdgpu]
août 30 12:40:43 jupiter.solsys.org kernel: amdgpu_dm_init.isra.0+0x5d5/0x800 [amdgpu]
août 30 12:40:43 jupiter.solsys.org kernel: ? __pfx_enable_assr+0x10/0x10 [amdgpu]
août 30 12:40:43 jupiter.solsys.org kernel: ? __pfx_update_config+0x10/0x10 [amdgpu]
août 30 12:40:43 jupiter.solsys.org kernel: dm_hw_init+0x12/0x30 [amdgpu]
août 30 12:40:43 jupiter.solsys.org kernel: amdgpu_device_ip_init+0x5dc/0x7b0 [amdgpu]
août 30 12:40:43 jupiter.solsys.org kernel: amdgpu_device_init.cold+0x3a3/0x975 [amdgpu]
août 30 12:40:43 jupiter.solsys.org kernel: amdgpu_driver_load_kms+0x1a/0x80 [amdgpu]
août 30 12:40:43 jupiter.solsys.org kernel: amdgpu_pci_probe+0x1b6/0x4d0 [amdgpu]
août 30 12:40:43 jupiter.solsys.org kernel: local_pci_probe+0x44/0xa0
août 30 12:40:43 jupiter.solsys.org kernel: pci_call_probe+0x53/0x190
août 30 12:40:43 jupiter.solsys.org kernel: pci_device_probe+0x84/0x170
août 30 12:40:43 jupiter.solsys.org kernel: ? srso_alias_return_thunk+0x5/0xfbef5
août 30 12:40:43 jupiter.solsys.org kernel: really_probe+0xf6/0x370
août 30 12:40:43 jupiter.solsys.org kernel: ? pm_runtime_barrier+0x55/0xa0
août 30 12:40:43 jupiter.solsys.org kernel: __driver_probe_device+0x8c/0x140
août 30 12:40:43 jupiter.solsys.org kernel: driver_probe_device+0x24/0xd0
août 30 12:40:43 jupiter.solsys.org kernel: __driver_attach+0xe4/0x210
août 30 12:40:43 jupiter.solsys.org kernel: ? __pfx___driver_attach+0x10/0x10
août 30 12:40:43 jupiter.solsys.org kernel: bus_for_each_dev+0x8c/0xf0
août 30 12:40:43 jupiter.solsys.org kernel: driver_attach+0x1e/0x30
août 30 12:40:43 jupiter.solsys.org kernel: bus_add_driver+0x14e/0x240
août 30 12:40:43 jupiter.solsys.org kernel: driver_register+0x73/0xf0
août 30 12:40:43 jupiter.solsys.org kernel: __pci_register_driver+0x5e/0x70
août 30 12:40:43 jupiter.solsys.org kernel: amdgpu_init+0x6a/0xff0 [amdgpu]
août 30 12:40:43 jupiter.solsys.org kernel: ? __pfx_amdgpu_init+0x10/0x10 [amdgpu]
août 30 12:40:43 jupiter.solsys.org kernel: do_one_initcall+0x5b/0x330
août 30 12:40:43 jupiter.solsys.org kernel: do_init_module+0x97/0x280
août 30 12:40:43 jupiter.solsys.org kernel: load_module+0x64d/0x750
août 30 12:40:43 jupiter.solsys.org kernel: init_module_from_file+0x96/0x100
août 30 12:40:43 jupiter.solsys.org kernel: idempotent_init_module+0x11d/0x310
août 30 12:40:43 jupiter.solsys.org kernel: __x64_sys_finit_module+0x5e/0xc0
août 30 12:40:43 jupiter.solsys.org kernel: x64_sys_call+0xfd1/0x2280
août 30 12:40:43 jupiter.solsys.org kernel: do_syscall_64+0x7e/0x170
août 30 12:40:43 jupiter.solsys.org kernel: ? srso_alias_return_thunk+0x5/0xfbef5
août 30 12:40:43 jupiter.solsys.org kernel: ? srso_alias_return_thunk+0x5/0xfbef5
août 30 12:40:43 jupiter.solsys.org kernel: ? vm_mmap_pgoff+0x134/0x1c0
août 30 12:40:43 jupiter.solsys.org kernel: ? srso_alias_return_thunk+0x5/0xfbef5
août 30 12:40:43 jupiter.solsys.org kernel: ? ksys_mmap_pgoff+0x189/0x250
août 30 12:40:43 jupiter.solsys.org kernel: ? srso_alias_return_thunk+0x5/0xfbef5
août 30 12:40:43 jupiter.solsys.org kernel: ? syscall_exit_to_user_mode+0x7e/0x270
août 30 12:40:43 jupiter.solsys.org kernel: ? srso_alias_return_thunk+0x5/0xfbef5
août 30 12:40:43 jupiter.solsys.org kernel: ? do_syscall_64+0x8a/0x170
août 30 12:40:43 jupiter.solsys.org kernel: ? srso_alias_return_thunk+0x5/0xfbef5
août 30 12:40:43 jupiter.solsys.org kernel: ? do_syscall_64+0x8a/0x170
août 30 12:40:43 jupiter.solsys.org kernel: ? srso_alias_return_thunk+0x5/0xfbef5
août 30 12:40:43 jupiter.solsys.org kernel: ? do_syscall_64+0x8a/0x170
août 30 12:40:43 jupiter.solsys.org kernel: ? irqentry_exit+0x43/0x50
août 30 12:40:43 jupiter.solsys.org kernel: ? srso_alias_return_thunk+0x5/0xfbef5
août 30 12:40:43 jupiter.solsys.org kernel: ? exc_page_fault+0x96/0x1c0
août 30 12:40:43 jupiter.solsys.org kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e
août 30 12:40:43 jupiter.solsys.org kernel: RIP: 0033:0x7697b35e188d
août 30 12:40:43 jupiter.solsys.org kernel: Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4>
août 30 12:40:43 jupiter.solsys.org kernel: RSP: 002b:00007fff13c2ec28 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
août 30 12:40:43 jupiter.solsys.org kernel: RAX: ffffffffffffffda RBX: 0000631258b80b30 RCX: 00007697b35e188d
août 30 12:40:43 jupiter.solsys.org kernel: RDX: 0000000000000000 RSI: 00007697b377b441 RDI: 0000000000000016
août 30 12:40:43 jupiter.solsys.org kernel: RBP: 0000000000020000 R08: 0000000000000000 R09: 0000000000000002
août 30 12:40:43 jupiter.solsys.org kernel: R10: 0000000000000016 R11: 0000000000000246 R12: 00007697b377b441
août 30 12:40:43 jupiter.solsys.org kernel: R13: 0000631258b84470 R14: 0000631258b80340 R15: 0000631258b8c780
août 30 12:40:43 jupiter.solsys.org kernel: </TASK>
août 30 12:40:43 jupiter.solsys.org kernel: ---[ end trace 0000000000000000 ]---
août 30 12:40:43 jupiter.solsys.org kernel: usb usb8-port1: Cannot enable. Maybe the USB cable bad
That warning is when things were otherwise work as expected?
To rule out whether this is related to the reset sequence that happens in the USB 4 controller at bootup can you reproduce the same problems when the dock is connected to a non usb4 port and lid is closed?
heh. good catch. If I plug the dock into port 2 or 5, it works. It is weird, as port 5 should not handle display output apparently
So yes, it seems to be USB 4 related.
Powerseq warning is still there (have that one since 6.10 kernel). But the link_dp_capability
warning is gone.
Experiment with adding this debugging parameter to your kernel command line:
thunderbolt.host_reset=0
Then try the USB 4 port again.
putting that option:
Command line: BOOT_IMAGE=/boot/vmlinuz-6.10.7-061007-generic root=UUID=c9e0ed30-c1c4-4e4e-9b0b-41ee3f0140ab ro quiet splash thunderbolt.host_reset=0 vt.handoff=7
I don’t have the external screen displayed to enter the password to unlock the home partition.
I also don’t see the sddm.
I have to again, unplug and replug the USB-C to get the external screen to work.
Can to share the journal that goes with it on a gist? I want to understand why SDDM doesn’t show anything (hopefully the log shows).
You can have a look at the logs here: Private share (My Nextcloud share).
put both files there. The journal of the boot, and the sddm log since the boot time (filtered).
I don’t see that thunderbolt.host_reset=0
in the log. Can you add that and thunderbolt.dyndbg
too?
You’re right. Using journalctl -1 took the previous boot. Added it as journald-6.10.7.txt to the same link.
Will add the dyndbg and will upload it.
UPDATE: Added files sddm-dbg.txt and journald-6.10.7-dbg.txt with the requested paramaters passed to the kernel at boot.
To me it looks like there is an unexpected ordering that sddm is starting before the dock “hotplug event” is processed. Can you force thunderbolt.ko to be in your initramfs so it’s loaded before sddm starts?
Did add the thunderbolt modulel, but upon checking, it was already added (Added it via hook call).:
smurphy@jupiter:/tmp/initrd$ grep thunderbolt initramfs_logs
Adding module /lib/modules/6.10.7-061007-generic/kernel/drivers/thunderbolt/thunderbolt.ko.zst
Adding module /lib/modules/6.10.7-061007-generic/kernel/drivers/net/thunderbolt/thunderbolt_net.ko.zst
Calling hook thunderbolt
Didn’t change the behavior. I still get the sddm login-screen where I can enter the password, and then no sync signal on the external screen.
2 things I noticed:
- The audio is detected from boot on. When I unplug the usb-c, it mentions the audio to be removed.
- The network card extension (USB-C 3.2 port) does also not work. I have to unplug and re-plug it.
I rather think that something happens behind the scene when the kernel is booted against when systemd took over. Sadly, as long as I did not unplug-replug the usb-c, I can’t access any screen/console.
@Mario_Limonciello Well with all the testing and stuff, my thunderbolt dock stopped working as dock it seems. Dunno if the cable or so is broken or the USB hub in the left side of my laptop.
Only getting:
$ boltctl list
○ Dell WD19TB Thunderbolt Dock
├─ type: peripheral
├─ name: WD19TB Thunderbolt Dock
├─ vendor: Dell
├─ uuid: ca030000-0060-6c0e-835b-33144c64d821
├─ generation: Thunderbolt 3
├─ status: disconnected
├─ authorized: mer. 04 sept. 2024 07:09:29
├─ connected: mer. 04 sept. 2024 07:09:29
└─ stored: mer. 13 mars 2024 09:34:23
├─ policy: iommu
└─ key: no
Not connected anymore. In a USB 3.2 slot was the only slot where I had a reaction still. Partial reaction.
Correction - it seems that Thunderbolt function has completely stopped on the left side. Reason unknown. Ethernet extension and audio still work, USB-C to dock remains silent.
Power cycle the dock maybe?
Tried. Will have to let it rest for a while. Guess that if plugged to the PC, it still gains enough power to maintain its current state.