Hello, Am 30.12.22 um 10:28 schrieb Mika Westerberg: > Him > > On Fri, Dec 30, 2022 at 08:57:37AM +0100, Christian Schaubschläger wrote: >> Hi, >> >> Am 27.12.22 um 15:28 schrieb Mika Westerberg: >>> Hi, >>> >>> On Fri, Dec 23, 2022 at 12:24:35PM +0100, Christian Schaubschläger wrote: >>>> Hello list, >>>> >>>> I'm having an issue which I guess might be related to thunderbolt 4. >>>> >>>> I have an HP EliteBook 630 G9 notebook and an HP Thunderbolt Dock G4, both with Thunderbolt 4. I run linux on it and need a working network interface (the one on the dock) in the UEFI firmware for PXE boot. >>>> >>>> When I come from a cold boot, the thunderbolt connection works well both in the UEFI firmware (I can do PXE), and also later in linux. After a reboot from linux, the dock disappears from the PCI bus and is no longer accessible in the UEFI firmware. Hence a PXE boot is not possible. When I then boot into linux again, the dock is there again, working just fine. >>>> >>>> On my machine the thunderbolt controller has the PCI address 0000.00.0d.2, and the PCI bridge to the dock has the address 0000.00.07.0. >>>> I've attached the PCI config spaces of these two devices as they are seen from the UEFI firmeware from two different states: >>>> >>>> 1. When the machine comes from a cold boot. In that state the UEFI firmware sees the dock and all devices on the dock. >>>> 2. When the machine comes from a linux reboot. In that state the dock is not visible on the PCI bus. >>>> >>>> The config spaces of the mentioned two devices are different in the two states. >>>> >>>> Note: once the machine is in state 2, it is necessary to remove the power supply from the dock (or physically disconnect and re-connect the thunderbolt cable) in order to get it working in UEFI again. That's what "cold boot" above actually means. >>>> >>>> Also, when the machine is in state 2 and boots into Windows the dock does not not become visible on the PCI bus. Interestingly, after a subsequent reboot from Windows it does become avialable in UEFI again (no need to disconnect the power supply or thunderbolt cable in this case!!) >>>> >>>> So I guess the linux kernel does something on shutdown (or misses to do something) that prevents the dock to wake up again after the reboot in the UEFI firmware. >>>> >>>> I'm observing this on all kernels I've tried (5.18.x, 6.0.x, 6.1.x; also when I run a vanilla Ubuntu 22.04 this happens); the logs below are from a pre-release kernel from today (which will be 6.2-rc1 in a few days). I've also experimented with some powersaving related settings on the kernel command line, unfortunately without success. >>>> >>>> Can anyone confirm this behaviour? >>> First of all can you check if you are running Intel or Microsoft driver >>> for the Thunderbolt controller? It can be seen in Device Manager >>> somehow. It is possible that Windows and Linux use different "connection >>> manager" so that explains why there is a difference in behaviour. >> The TB contoller in Windows uses the Intel driver, the dock itself a driver from Microsoft. > Okay then it is using "Firmware Connection Manager" whereas Linux is > using "Software Connection Manager" so completely diffrent things. > >>> In case of Linux this is software connection manager so it is Linux that >>> does all the tunneling. In case of Windows it may be also firmware >>> connection manager so it is handled in the firmware (and this might >>> explain why it magically works after rebooting from Windows). >>> >>> In general this depends on the BIOS setting whether there is PCIe tunnel >>> or not. Typically there is something like "boot from Thunderbolt" or >>> similar option that turns it on so I suggest checking if you have >>> such option. >> Unfortunately there is no such BIOS setting on this machine... >> >> But as described above: when the laptop comes from a cold boot (with >> power supply removed before, etc.), then there _is_ a PCIe tunnel in >> the UEFI firmware; so the firmware can do that. Only after a reboot >> from Linux something prohibits the firmware from re-establishing the >> tunnel again. And I'm not sure if this is a kernel issue or a firmware >> issue, but it clearly makes a valid use case (pxe boot after linux) >> impossible. >> >> Can I do anything to bring more light to this problem? > One thing you can try is to "force" Linux to use the same FW CM path > than Windows. This is done by compiling your kernel with CONFIG_USB4=n. > This should enable the firmware CM in Linux side as well. All the > tunneling (except software/networking/P2P) should work with it even if > the Thunderbolt driver is not loaded. I wonder if you can try that and > see if the PXE starts working better? Ok, setting CONFIG_USB4=n makes everything work as expected! Even hotplugging the dock works fine. Now I've tried this: CONFIG_USB4=m and blacklist the thunderbolt module (because disabling CONFIG_USB4 in general is not an option for me (I guess?) There's probably hardware out there where the firmware doesn't set up the PCIe tunnels. Then I need the linux thunderbolt driver to do this I suppose). So with CONFIG_USB=m and blacklisting the thunderbolt module this happens: the tunnel is there before and after linux (PXE works), but in linux none of the devices that sit behind the PCIe tunnel (network, external display) are there... that's strange, because I would have expected that CONFIG_USB4=m + blacklist thunderbolt would be the same as CONFIG_USB4=n. Which obviously isn't the case. I've attached lspci output from either case. Is there any other option to decide at boottime whether or not to use the USB4 driver (besides using two different kernels)? Thanks and best regards, Christian
Attachment:
lspci_vv_no_usb4.txt.xz
Description: application/xz
Attachment:
lspci_vv_blacklist_usb4.txt.xz
Description: application/xz
Attachment:
lspci_t_blacklist_usb4.txt.xz
Description: application/xz
Attachment:
lspci_t_no_usb4.txt.xz
Description: application/xz
