adl: Devices in TBT port not detected on boot

[crawfxrd]

• Model: All ADL models
• BIOS version:
• EC version:
• OS:

On the ADL models, any device (storage, display) in the TBT port is not detected at boot.

Steps to reproduce

• Power off system
• Plug in device to TBT port
• Boot to desktop

Expected behavior

• Storage device is enumerated in lsblk
• Display is detected in Settings

Actual behavior

• Device is not detected until it is removed and replugged

Additional info

[redsie]

Lemur Pro 11 / i7-1255U - the same issue, opened a ticket (ID 85021) with System76. I think it may be related to the default thunderbolt security level set to 'user'.

[adeptg]

Same here with darp8 and the external USB-C display: when the display is connected, and I reboot the laptop, the laptop doesn't detect the display till I unplug it and plug it again.
I reported the issue to support a few days ago (ticket ID is 100629), don't have an answer yet.

[asiftali]

Same. I also opened a ticket (103898) which led me here.

I can also confirm that on my lemp11 that the output of boltctl domains is showing the security level as iommu+user. I think having the ability to change this to something like secure and in addition being able to add bootacls is what I've seen being used in other systems.

[Kirizan]

I am facing the same issue. It's quite annoying to have to log into the OS just to use my keyboard, mouse, and monitor. It really makes it impossible to use the laptop closed. I'm still very new to using Linux as a desktop os, so I'm glad it's not just me with this issue.

[antonkulaga]

EGPU does not work for me at all. Even plugging and unplugging do not help. I wrote to System76 support, but they were pretty useless and did not suggest anything (other than installing newer driver that I did myself together with many other options, like egpu-switcher that never worked)

[leviport]

but they were pretty useless

reminder: https://github.com/pop-os/code-of-conduct

[jtegtmeier]

Seems to be a similar issue with oryp10. Unplugging and plugging the Thunderbolt/USB-C dock back in resolves the issue temporarily (edit: until next boot), but is quite tedious.

[shubb30]

I am having a similar (yet slightly different) issue. I have a Darter Pro, and am using a CalDigit TB dock. When I plug in my two monitors, they are both detected correctly. As soon as I reboot, they are not detected. If I booth with the TB disconnected, and then plug in the TB dock, only one monitor is detected, and the second is not. Thinking the cable was bad, I swapped the cables between the two monitors, and they both were detected again. Rebooting, brought be back to the same problem where only 1 works when plugging the dock in after boot.

[ravdiculous]

For visibility, I am seeing this issue on the orpy11. Thank you to anyone who has time to work on this!

[dustinlennon]

I want to thank Francis in customer support for bringing my attention to this bug report / thread. I'm also running into the same issue on lemp11.

One of the things I looked into was how udev reports before / after a replugging. That is, running the following command:

sudo udevadm info --attribute-walk --path=/sys/devices/pci0000:00/0000:00:0d.2/domain0/0-0

In what follows, recall that for the lemp11, 0000:00:0d.2 has the relevant lspci entry:

00:0d.2 USB controller: Intel Corporation Alder Lake-P Thunderbolt 4 NHI #0 (rev 04)

Before the replugging, I obtained

  looking at device '/devices/pci0000:00/0000:00:0d.2/domain0/0-0':
    KERNEL=="0-0"
    SUBSYSTEM=="thunderbolt"
    ATTR{authorized}=="1"
    ATTR{device}=="0x463e"
    ATTR{device_name}=="Gen12"
    ATTR{generation}=="4"
    ATTR{power/async}=="disabled"
    ATTR{power/control}=="auto"
    ATTR{power/runtime_enabled}=="enabled"
    ATTR{power/runtime_status}=="suspended"
    ATTR{unique_id}=="a2a78780-5064-250f-ffff-ffffffffffff"
    ATTR{vendor}=="0x8087"
    ATTR{vendor_name}=="INTEL"
    ATTR{waiting_for_supplier}=="0"

and after,

  looking at device '/devices/pci0000:00/0000:00:0d.2/domain0/0-0':
    KERNEL=="0-0"
    SUBSYSTEM=="thunderbolt"
    ATTR{authorized}=="1"
    ATTR{device}=="0x463e"
    ATTR{device_name}=="Gen12"
    ATTR{generation}=="4"
    ATTR{power/async}=="disabled"
    ATTR{power/control}=="auto"
    ATTR{power/runtime_enabled}=="enabled"
    ATTR{power/runtime_status}=="active"
    ATTR{unique_id}=="a2a78780-5064-250f-ffff-ffffffffffff"
    ATTR{vendor}=="0x8087"
    ATTR{vendor_name}=="INTEL"

The key difference that power/runtime_enabled goes from "suspended" to "active"

Looking at some of the change logs in /boot/efi/system76-firmware-update/firmware, and after a cursory review of the git logs, it seems like one of the themes of recent updates have been related to suspension/power settings.

I'm wondering if this connection might be helpful in resolving the replugging issue. Is it possible to change the firmware code so that the NHI be brought up in "active" mode? Alternatively, is there something that can be done post-boot, like triggering an event, that might force the NHI into "active" mode?

It's possible (likely) that I'm barking up the wrong tree. If so, my apologies for the noise, and please let me know so I can turn this into a learning opportunity.

thanks!
Dustin

[dustinlennon]

@crawfxrd, I've been back and forth with Francis in the last three weeks. He has insinuated that this issue isn't likely to be addressed any time soon. I'm wondering if you have any more information on its prioritization. Thanks!

[leviport]

It's prioritized relatively highly and we are working on it. We just haven't gotten to the root cause yet. We will keep this issue updated when there are updates to share. No need for the pings.

[ravdiculous]

It's prioritized relatively highly and we are working on it. We just haven't gotten to the root cause yet. We will keep this issue updated when there are updates to share. No need for the pings.

Thanks so much for the time your team is putting into this! If there are any logs that I can pull from my machine for you, please let me know. Otherwise, godspeed 🖖

[inferentialist]

I received this update today from the System76 help desk:

Our tech support team is really not qualified to fix this issue. Please refer to the github issue for progress on this.

Apologies for pinging the thread again, but this seems to be where System76 expects customers to resolve these sorts of problems.

A digression

One reads the code of conduct and imagines that this github repo would be a contributor friendly thread. In fact, several of us here, albeit perhaps ignorantly, have enthusiastically volunteered to help in whatever way we can. However, there hasn't been any uptake making it difficult to contribute in a positive capacity.

It was also a bit surprising (to me, anyway) to discover that this forum is presented--again, through the code of conduct--as an open community to improve Pop!OS. Surprising, because it's also apparently intended to function as crowdsourced technical support for System76 customers.

... in terms of customer experience, this is all very uncomfortable :(

[crawfxrd]

There is nothing for users to contribute for this issue. I'm able to reproduce it. I'm unable to determine the cause.

[leviport]

There appears to be a bit of a misunderstanding, so I'd just like to clarify a bit.

Please refer to the github issue for progress on this.

was not intended to translate into

also apparently intended to function as crowdsourced technical support for System76 customers.

This is open source firmware, so customers get front row seats, if they want to spectate. Our Support Team was only pointing towards the first place where new information would be available. Since it's open source, customers are free to get involved if they want to, but we have no expectation that they do so. Hopefully that clarifies things a little. Thank you for your patience while we work on this tricky bug.

[inferentialist]

I didn't want to assume that open firmware is an issue for which there wouldn't be any customer support. So, the feedback is helpful in that regard. I've asked the help desk to close my ticket.

To that end, is there any possibility of reverting back to a manufacturer's firmware?

[ravdiculous]

@crawfxrd and @leviport, thank you again for all the time spent on this. There's only so much time one can spend banging their head against a problem like this. Especially when there are other demands on your time.

Keep on keeping on 🔥

[crawfxrd]

This is not resolved by:

• Updated CSME
• Updated coreboot
• Updated edk2

Will have to look as coreboot and FSP configs next.

[crawfxrd]

Doesn't seem to be something as simple as changing Kconfigs or FSP values.

src/soc/intel/common/block/tcss/Kconfig is the only thing left that I see that looks relevant:

config ENABLE_TCSS_DISPLAY_DETECTION
	bool "Enable detection of displays over USB Type-C ports with TCSS"
	depends on SOC_INTEL_COMMON_BLOCK_TCSS && RUN_FSP_GOP
	help
	  Enable displays to be detected over Type-C ports during boot.

config ENABLE_TCSS_USB_DETECTION
	bool "Enable detection of USB boot devices attached to USB Type-C ports with TCSS"
	depends on SOC_INTEL_COMMON_BLOCK_TCSS
	help
	  Enable USB-C attached storage devices to be detected at boot.
	  This option is required for some payloads (eg, edk2), without which devices attached
	  to USB-C ports will not be detected and available to boot from.

Ref: CB:72909

---

Selecting those and adding a non-null usbc_get_ops makes detection of my USB storage devices work.

[ddetton]

I don't know if the issue I am working is related to this or not but here are the details. System76 case# 157412. For those that don't have access to S76 cases, here are the details:

I know that Windows is not officially supported for System76 laptops but I have a question about Thunderbolt. I have an Oryx Pro (oryp11) and I just installed Windows 11 on a dedicated nvme drive. It is mostly working except that it is having a problem with the Thunderbolt Controller. The device manager reports that "Windows has stopped this device because it has reported problems (code 43). I have installed all of the windows drivers on the system76 github and I still have this issue. I have run the Intel Driver Update utility and all drivers are reported current. I know that the thunderbolt device I am trying to use (Plugable TBT3-UDZ) is good because I can plug it into an older HP Windows 11 laptop and it works fine. The thunderbolt driver on the Windows 11 laptop is dated 9-3-2018 where the driver date on the oryp11 is 5-23-23. Btw, this same device works fine in pop-os! on the same hardware. I have also tried this on a fresh Windows 10 install with same results. Thunderbolt Controller will not load. Removing and reapplying the TB3 cable does not restore function. Also, if I plug a usb-c thumb drive into the TB3 port, it works fine.

[mirsev]

Hi, can I ask if this issue will be fixed in oryp10 soon?

[bl3chd0se]

As the issue is still unresolved after two years and it renders my lemp11 unusable for eGPU and fully working docking, may I ask when we can expect a fix for this?

[alethascribe]

Mine (lemp) too. I cannot connect to my eGPU or my thunderbolt external drive bay. However, I don't have this issue on my meerkat. On the meerkat, I can connect my eGPU at all and it registers after reboot. It handles one external bay fine, however it refuses to connect both external bays, in spite of having two thunderbolt ports. I can have the eGPU on one thunderbolt port, and the external bay on the other, though.

I would really like the thunderbolt issues to be resolved, so I can use my devices as I had intended.

(And I tried connecting the eGPU and external bays to a non-system76 machine, and they worked fine. Seems to be a sys76 problem.)