Bug 206459

Summary: thinkpad thunderbolt 3 dock gen2 pci memory allocation errors on Yoga C940 unless plugged in before boot
Product: Drivers Reporter: Benoit Grégoire (benoitg)
Component: PCIAssignee: drivers_pci (drivers_pci)
Status: NEW ---    
Severity: normal CC: bjorn, etienne.dysli+kernelbug, kjhambrick, knyffen, mika.westerberg, mumblingdrunkard, nicholas.johnson-opensource, vinci.petrillo, wse
Priority: P1    
Hardware: Intel   
OS: Linux   
Kernel Version: 5.5.2 Subsystem:
Regression: No Bisected commit-id:
Attachments: acpidump
mainline_5.5.2_notworking_dmesg_dock_plugged_after_boot
mainline_5.5.2_notworking_lspci_vvvv_dock_plugged_after_boot
mainline_5.5.2_notworking_lsusb_dock_plugged_after_boot
mainline_5.5.2_working_dmesg_dock_plugged_before_boot
mainline_5.5.2_working_lspci_vvvv_dock_plugged_before_boot
mainline_5.5.2_working_lsusb_dock_plugged_before_boot
mainline_5.6rc2_working_dmesg_dock_plugged_before_boot
mainline_5.6rc2_working_lspci_xxxx_dock_plugged_before_boot
mainline_5.6rc2_working_lspci_vt_dock_plugged_before_boot
mainline_5.6rc2_reference_lspci_vv_dock_not_plugged
mainline_5.6rc2_reference_dmesg_dock_not_plugged
mainline_5.6rc2_notworking_lspci_vv_dock_plugged_second_port_after_boot
mainline_5.6rc2_notworking_dmesg_dock_plugged_second_port_after_boot
mainline_5.6rc2_notworking_dmesg_dock_plugged_after_boot
mainline_5.6rc2_notworking_dmesg_dock_replugged_after_boot
mainline_5.6rc2_working_dmesg_pci_dyndbg_dock_plugged_before_boot
mainline_5.6rc2_working_lspci_vnnt_dock_plugged_before_boot
mainline_5.6rc2_notworking_dmesg_pci_dyndbg_dock_plugged_after_boot
mainline_5.6rc2_cat_proc_iomem_before_attach
mainline_5.6rc2_cat_proc_iomem_after_attach
mainline_5.6rc2_working_dmesg_pci_dyndbg_dock_plugged_before_boot
mainline_5.6rc2_notworking_dmesg_pci_dyndbg_dock_plugged_after_boot
mainline_5.6rc2_notworking_dmesg_pci_dyndbg_dock_plugged_after_boot_hpmensize_0
Don't align upstream port resources
mainline_5.6rc2_notworking_dmesg_dock_plugged_after_boot_2020-02-21_patch
Skip clipping e820 regions
Do not exclude regions marked as MMIO in EFI memmap
mainline_5.6rc3_working_dmesg_dock_plugged_after_boot_patch_287619
mainline_5.6rc3_working_dmesg_dock_plugged_after_boot_patch_287661
experimental patch
dmsg of experimental patch, dock attached before boot
dmsg of experimental patch, dock attached after boot
add resource clip debug
dmsg of experimental patch, dock attached before boot 2
dmsg of experimental patch, dock attached after boot 2
6.0.10 Logs

Description Benoit Grégoire 2020-02-07 19:52:30 UTC
Created attachment 287231 [details]
acpidump

I have thinkpad thunderbolt 3 dock gen2 dock I am trying to use with a New Lenovo Yoga C940-14IIL laptop.  Laptop is very recent hardware, with a 10th gen intel cpu, and a bios with very few options :(

- The dock works fine when plugged-in before boot.
- The dock does NOT work when plugged after the system booted.
- The dock does NOT work when plugged-in at boot, subsequently unplugged and plugged back in.
- The dock work fine in windows, in all the above scenarios

When it fails, it fails with memory allocation messages such as:

[ 342.507320] pci 0000:2b:00.0: BAR 14: no space for [mem size 0x0c200000]
[ 342.507323] pci 0000:2b:00.0: BAR 14: failed to assign [mem size 0x0c200000]

Things I tried:
- Ubuntu kernel 5.3.0-26, same symptoms
- Kernel mainline 5.4.12, same symptoms
- Kernel mainline 5.5.2, same symptoms, but gets a little further allocating memory on the second pass.
- Plugging the dock after powering up the laptop, but at the grub screen before boot. In this case the dock works fine after boot.

Other potentially useful information to narrow it down:

- The tests were done with only an ethernet cable and power plugged into the dock to minimize the number of moving parts...

- Dock and laptop both have the very latest firmware as of 2020-02-07
cat /sys/bus/thunderbolt/devices/0-0/nvm_version
72.0
cat /sys/bus/thunderbolt/devices/0-3/nvm_version
50.0

- Unfortunately I cannot procure older firmware for the dock to know if the laptop or the dock is the source of the problem (As this dock was released over a year ago, and I cannot find any specific relevant problems with Linux)

- The screens connected to the displayports on the dock always work. But but all other ports (USB, ethernet, sound fail) when plugged-in after boot.

- Doesn't seem to be a thunderbolt authorization problem:
tbtadm devices 
0-3     Lenovo  ThinkPad Thunderbolt 3 Dock     authorized      not in ACL

Originally reported to ubuntu in: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284
Comment 1 Benoit Grégoire 2020-02-07 19:54:07 UTC
Created attachment 287233 [details]
mainline_5.5.2_notworking_dmesg_dock_plugged_after_boot
Comment 2 Benoit Grégoire 2020-02-07 19:54:41 UTC
Created attachment 287235 [details]
mainline_5.5.2_notworking_lspci_vvvv_dock_plugged_after_boot
Comment 3 Benoit Grégoire 2020-02-07 19:55:04 UTC
Created attachment 287237 [details]
mainline_5.5.2_notworking_lsusb_dock_plugged_after_boot
Comment 4 Benoit Grégoire 2020-02-07 19:55:24 UTC
Created attachment 287239 [details]
mainline_5.5.2_working_dmesg_dock_plugged_before_boot
Comment 5 Benoit Grégoire 2020-02-07 19:55:46 UTC
Created attachment 287241 [details]
mainline_5.5.2_working_lspci_vvvv_dock_plugged_before_boot
Comment 6 Benoit Grégoire 2020-02-07 19:56:10 UTC
Created attachment 287243 [details]
mainline_5.5.2_working_lsusb_dock_plugged_before_boot
Comment 7 Benoit Grégoire 2020-02-17 21:21:44 UTC
Still no luck on 5.5.4, and with an updated BIOS (AUCN54WW)

Is there any other information I could provide?
Comment 8 Nicholas Johnson 2020-02-18 00:27:45 UTC
Hi Benoit,

Please try Linux v5.6-rc2: https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.6-rc2/

I have seven patches directly relating to Thunderbolt PCI native enumeration in the v5.6 release, which may help.

In the future, please note that "sudo lspci -xxxx" dumps all information into a file, allowing us to run any lspci command from that file, as if it were on your system. "lspci -F file -vt" for example. I like to have -vt to get a feel for the topology, especially for Thunderbolt.

Thanks for reporting.

Regards,
Nicholas
Comment 9 Mika Westerberg 2020-02-18 07:43:59 UTC
In case the v5.6-rcX kernel does not help, can you boot the system without device connected and attach 'sudo lspci -vv' and also full dmesg? It looks like the root port (07.1) gets misconfigured by Linux for some reason upon hotplug.

Another question, if you plug the device to another port, does it work any better? Can you attach 'sudo lspci -vv' and dmesg output of that run as well?
Comment 10 Benoit Grégoire 2020-02-18 18:09:49 UTC
Created attachment 287469 [details]
mainline_5.6rc2_working_dmesg_dock_plugged_before_boot
Comment 11 Benoit Grégoire 2020-02-18 18:10:56 UTC
Created attachment 287471 [details]
mainline_5.6rc2_working_lspci_xxxx_dock_plugged_before_boot
Comment 12 Benoit Grégoire 2020-02-18 18:11:50 UTC
Created attachment 287473 [details]
mainline_5.6rc2_working_lspci_vt_dock_plugged_before_boot
Comment 13 Benoit Grégoire 2020-02-18 18:12:25 UTC
Created attachment 287475 [details]
mainline_5.6rc2_reference_lspci_vv_dock_not_plugged
Comment 14 Benoit Grégoire 2020-02-18 18:12:48 UTC
Created attachment 287477 [details]
mainline_5.6rc2_reference_dmesg_dock_not_plugged
Comment 15 Benoit Grégoire 2020-02-18 18:13:58 UTC
Created attachment 287479 [details]
mainline_5.6rc2_notworking_lspci_vv_dock_plugged_second_port_after_boot
Comment 16 Benoit Grégoire 2020-02-18 18:14:40 UTC
Created attachment 287481 [details]
mainline_5.6rc2_notworking_dmesg_dock_plugged_second_port_after_boot
Comment 17 Benoit Grégoire 2020-02-18 18:15:12 UTC
Created attachment 287483 [details]
mainline_5.6rc2_notworking_dmesg_dock_plugged_after_boot
Comment 18 Benoit Grégoire 2020-02-18 18:15:38 UTC
Created attachment 287485 [details]
mainline_5.6rc2_notworking_dmesg_dock_replugged_after_boot
Comment 19 Benoit Grégoire 2020-02-18 18:19:48 UTC
Hello Nicholas and  Mika,

Unfortunately, 5.6rc2 didn't help.

See the new attachments, I believe I included all the information requested. 

In addition, I included separate dmesg for when the dock is plugged after boot, and when it was plugged before boot and subsequently re-plugged.

Thanks for your help!
Comment 20 Nicholas Johnson 2020-02-19 02:38:12 UTC
Thanks for the additional information, Benoit.

If you have other Thunderbolt 3 devices, do they also cause issues with this computer?

Do you have another Thunderbolt 3 computer to boot Linux to try the dock?

Please give "lspci -vnnt" with dock attached before boot and working so I can be sure of topology.

Mika, do you think it could it be worth changing the ACPI OSI name to mimic Windows to see if ACPI is treating us differently?

I see there is a conflict with reserved memory (I have never seen this before) but it is with the SPI controller, not Thunderbolt.

The dmesg suggests booting with pci=realloc. It is worth that with Ice Lake, Linux refuses to reassign (my theory is that ACPI _DSM method evaluates to zero).

I would really like the struct resource to be changed in Linux so that the desired alignment is preserved after assignment, so that we can see it. I suspect the dock has funny alignment expectations which we cannot easily see.

For future tests, you may want to pass pci.dyndbg to kernel parameters to give more information.

This is a bunch of random thoughts and observations for now. I will continue to scour the logs for clues.
Comment 21 Nicholas Johnson 2020-02-19 03:01:33 UTC
Benoit, are you comfortable compiling and running your own kernel?
Comment 22 Benoit Grégoire 2020-02-19 03:05:34 UTC
Created attachment 287493 [details]
mainline_5.6rc2_working_dmesg_pci_dyndbg_dock_plugged_before_boot
Comment 23 Benoit Grégoire 2020-02-19 03:06:04 UTC
Created attachment 287495 [details]
mainline_5.6rc2_working_lspci_vnnt_dock_plugged_before_boot
Comment 24 Benoit Grégoire 2020-02-19 03:09:38 UTC
Nicholas, see the two new files with the info you requested (dmesg with pci.dyndbg, and lspci -vnnt)

Unfortunately, I do not have another thunderbolt3 peripheral or other machine with thunderbolt3 on hand.

Yes, I can compile my own kernel to test things if it helps.
Comment 25 Nicholas Johnson 2020-02-19 03:11:51 UTC
Thanks Benoit, I will have a look at them.

Here is another person who was having issues specifically with MMIO resource window when hot plugging. I think it could be related (same bug?):

https://lore.kernel.org/linux-pci/PSXP216MB0438BE9DA58D0AF9F908070680540@PSXP216MB0438.KORP216.PROD.OUTLOOK.COM/T/
Comment 26 Nicholas Johnson 2020-02-19 03:13:58 UTC
Sorry, I you had already given an lspci -vt which was sufficient, I forgot to drop that request before posting.

Could we please have dyndbg after the dock has been hot-added after boot? Thanks
Comment 27 Benoit Grégoire 2020-02-19 04:19:32 UTC
Created attachment 287501 [details]
mainline_5.6rc2_notworking_dmesg_pci_dyndbg_dock_plugged_after_boot
Comment 28 Benoit Grégoire 2020-02-19 04:20:08 UTC
Sure, see new attachment
Comment 29 Nicholas Johnson 2020-02-19 05:36:02 UTC
Hi Benoit,

It does not contain the information I am expecting.

I need to see the pci_dbg() calls at lines 1855 and 1859 here:

https://elixir.bootlin.com/linux/v5.6-rc2/source/drivers/pci/setup-bus.c

Perhaps your log level is excluding them. Can you please see if you can adjust dmesg log level to see "extended by" and "shrunken by"?

Thanks!
Comment 30 Nicholas Johnson 2020-02-19 05:40:05 UTC
There could be a possibility that they all have new_size = size and are skipping the pci_dbg(), but I find that unlikely. But if this is the case then I apologise.
Comment 31 Nicholas Johnson 2020-02-19 05:43:29 UTC
Could I please also have "sudo cat /proc/iomem" before and after dock attached? Must be sudo or else it excludes address information. This gives a complete overview of resources. Thanks
Comment 32 Benoit Grégoire 2020-02-19 06:46:09 UTC
Created attachment 287503 [details]
mainline_5.6rc2_cat_proc_iomem_before_attach
Comment 33 Benoit Grégoire 2020-02-19 06:47:31 UTC
Created attachment 287505 [details]
mainline_5.6rc2_cat_proc_iomem_after_attach
Comment 34 Benoit Grégoire 2020-02-19 06:48:20 UTC
I don't know, I seem to get the messages generated at https://
elixir.bootlin.com/linux/v5.6-rc2/source/drivers/pci/pci.c#L1378 , line 1378.  
I really don't know what could be filtering the specific ones you want.

The two iomem files are attached above.
Comment 35 Mika Westerberg 2020-02-19 08:36:32 UTC
(In reply to Nicholas Johnson from comment #20)
> Mika, do you think it could it be worth changing the ACPI OSI name to mimic
> Windows to see if ACPI is treating us differently?

Linux should do that by default e.g Linux looks like Windows to the ACPI code.
Comment 36 Mika Westerberg 2020-02-19 08:52:30 UTC
Can you check if you have CONFIG_PCI_DEBUG=y enabled in your .config? If not please enable it and attach full dmesg of the failure. I think that option is also needed to see the additional debugging information regarding resource allocation and more.
Comment 37 Benoit Grégoire 2020-02-19 18:28:05 UTC
Created attachment 287511 [details]
mainline_5.6rc2_working_dmesg_pci_dyndbg_dock_plugged_before_boot
Comment 38 Benoit Grégoire 2020-02-19 18:28:38 UTC
Created attachment 287513 [details]
mainline_5.6rc2_notworking_dmesg_pci_dyndbg_dock_plugged_after_boot
Comment 39 Benoit Grégoire 2020-02-19 18:29:56 UTC
Ok, thanks Mika.  I compiled my own kernel and the attachments above now have the information Nicholas wanted.
Comment 40 Mika Westerberg 2020-02-20 09:03:51 UTC
I'm still going through your log but in the meantime one option you could try is to put "pci=hpmemsize=0" into the kernel command line and see if it makes any difference.
Comment 41 Benoit Grégoire 2020-02-21 00:41:36 UTC
Created attachment 287523 [details]
mainline_5.6rc2_notworking_dmesg_pci_dyndbg_dock_plugged_after_boot_hpmensize_0

Attempt with pci=hpmemsize=0
Comment 42 Mika Westerberg 2020-02-21 09:46:49 UTC
Created attachment 287533 [details]
Don't align upstream port resources

Can you try the attached patch? For some reason we fail already when the upstream port (2b:00.0) resources are assigned which is weird because it should simply get all the resources. This one also adds couple of debug prints more so please attach full dmesg.

You can also remove "pci=hpmemsize=0" from the command line since it did not help.
Comment 43 Benoit Grégoire 2020-02-22 05:03:18 UTC
Created attachment 287551 [details]
mainline_5.6rc2_notworking_dmesg_dock_plugged_after_boot_2020-02-21_patch

Unfortunately, the patch did not help
Comment 44 Mika Westerberg 2020-02-25 13:45:15 UTC
I have been trying to reproduce this on my reference ICL system without success but today I got my hands on a recent Lenovo Yoga and it has the same issue so now I can reproduce it :) I'll update this as soon as I have some idea what the root cause might be.
Comment 45 Benoit Grégoire 2020-02-25 19:23:27 UTC
That's great news for me!  Thanks a lot Mika, and good luck...
Comment 46 Mika Westerberg 2020-02-26 15:37:39 UTC
Created attachment 287619 [details]
Skip clipping e820 regions

It looks like the Yoga BIOS-e820 memory map includes some of the memory space reserved for root bridge and the devices below it:

4bc50000-cfffffff               BIOS-e820 reserved area
  65400000-bfffffff             Root bridge
    66000000-721fffff           PCIe root port 07.1

There is code in arch/x86/kernel/resource.c (arch_remove_reservations()) that clips the resource so that it avoids these regions. This is why we can't find memory space for the upstream port.

I wonder if you can try the attached hack patch that skips the clipping?

The changelog in 4dc2287c1805 ("x86: avoid E820 regions when allocating address space") says that Windows seems to ignore these reserved regions which might explain why this works in Windows.
Comment 47 Mika Westerberg 2020-02-27 14:23:53 UTC
Created attachment 287661 [details]
Do not exclude regions marked as MMIO in EFI memmap

This patch is slightly better. Can you try this one?

Bjorn, can you check if this makes sense? The original code is from you so you know this much better than I :) This fixes the issue on Yoga S740 I have here.
Comment 48 Nicholas Johnson 2020-02-27 15:04:55 UTC
Nice catch. Does this affect all Thunderbolt peripherals with MMIO BAR? It sounds like it does.

More abstract questions for thought (not necessarily expecting any answers):
- Why did they do this, why does Windows ignore the reserved region, and why only Lenovo?
- Could this suggest Linux needs to be added into the certification requirements someday?

The thing I love about Ice Lake is it will hopefully give the OEMs less chance to mess up the Thunderbolt implementation than with external chips. However, clearly mistakes can still be made.
Comment 49 Benoit Grégoire 2020-02-27 18:30:53 UTC
Created attachment 287663 [details]
mainline_5.6rc3_working_dmesg_dock_plugged_after_boot_patch_287619

Result of trying patch 287619, it works!
Comment 50 Benoit Grégoire 2020-02-27 18:31:55 UTC
Created attachment 287665 [details]
mainline_5.6rc3_working_dmesg_dock_plugged_after_boot_patch_287661

Result of trying patch 287661, it ALSO works!  Many thanks!
Comment 51 Mika Westerberg 2020-03-02 15:05:39 UTC
Great, thanks for testing. I submitted the patch upstream now:

https://lore.kernel.org/lkml/20200302141451.18983-1-mika.westerberg@linux.intel.com/
Comment 52 Mika Westerberg 2020-03-02 15:07:51 UTC
(In reply to Nicholas Johnson from comment #48)
> Nice catch. Does this affect all Thunderbolt peripherals with MMIO BAR? It
> sounds like it does.

Yes, I think it does.
Comment 53 Benoit Grégoire 2020-06-16 22:26:34 UTC
Any chance this will make it into 5.8 ?
Comment 54 Mika Westerberg 2020-06-17 16:49:29 UTC
I just resent the patch. Hopefully it lands mainline at some point :)
Comment 55 Benoit Grégoire 2020-11-13 18:09:39 UTC
Just a testing update:  As of today (2020-11-12), the patch:
- Still hasn't landed
- Still applies cleanly on kernel 5.10-rc3
- Is still needed, otherwise thunderbolt doesn't work at all on affected hardware upon reconnect.
Comment 56 Mika Westerberg 2020-11-19 10:30:47 UTC
Hi, sorry about this. I did not get any comments from x86 maintainers for this and the comment from Bjorn (the author of the original code) seems to suggest rather big rework so I simply haven't had time to look at it at the moment. Can send a ping on that thread? Maybe we get some x86 maintainers to comment it then.
Comment 57 mumblingdrunkard 2021-03-24 23:10:35 UTC
Any updates on if a fix for this has arrived? So far I've just been applying the patch (287661) and compiling the kernel myself for my Yoga C940, but it's rather finnicky.
Comment 58 Mika Westerberg 2021-03-26 11:43:44 UTC
I suggest you to reply on that email thread that there is a real problem that needs to be solved so we get some traction from the maintainers.
Comment 59 Werner Sembach [TUXEDO] 2021-10-08 08:30:39 UTC
Just wanted to leave a note here that this issue continues to be a problem with descrete thundebold 4 chips: https://bugzilla.kernel.org/show_bug.cgi?id=214259

The hack from https://bugzilla.kernel.org/show_bug.cgi?id=206459#c46 fixes the dock on that Laptop, the cleaner hack I have yet to try.
Comment 60 Werner Sembach [TUXEDO] 2021-10-08 08:33:24 UTC
*** Bug 214259 has been marked as a duplicate of this bug. ***
Comment 61 Bjorn Helgaas 2022-11-19 21:56:34 UTC
From the dmesg log in https://bugzilla.kernel.org/attachment.cgi?id=287483,

  BIOS-e820: [mem 0x000000004bc50000-0x00000000cfffffff] reserved
  pci_bus 0000:00: root bus resource [mem 0x65400000-0xbfffffff window]
  pci 0000:00:07.1: PCI bridge to [bus 2b-54]
  pci 0000:00:07.1:   bridge window [mem 0x66000000-0x721fffff]
  # add dock
  pcieport 0000:00:07.1: pciehp: Slot(0-1): Card present
  pcieport 0000:00:07.1: pciehp: Slot(0-1): Link Up
  pci 0000:2b:00.0: BAR 14: no space for [mem size 0x0c200000]

From the log in https://bugzilla.kernel.org/attachment.cgi?id=287665, which includes the patch in https://bugzilla.kernel.org/attachment.cgi?id=287661 to "not exclude EFI MMIO regions":

  pci 0000:2b:00.0: BAR 14: assigned [mem 0x66000000-0x721fffff]

The 00:07.1 bridge window was the same in both cases, so the same space is available on bus 2b.  I think the reason the first one failed even though the space was available was because the entire MMIO aperture was marked "reserved" in E820, so PCI avoids assigning space from it.  The patch basically avoids that E820 checking if the region is EfiMemoryMappedIO.

The patch https://git.kernel.org/linus/d341838d776a ("x86/PCI: Disable E820 reserved region clipping via quirks") appeared in v5.19 and should work around this problem for this machine and others.
Comment 62 Bjorn Helgaas 2022-11-19 22:04:23 UTC
Created attachment 303237 [details]
experimental patch

That patch (d341838d776a ("x86/PCI: Disable E820 reserved region clipping via quirks")) relies on quirks that match DMI Vendor, Product Version, Product Name, and Board Name.  This isn't an ideal solution because there are likely other systems we don't know about that need the a similar fix.

The patch I'm attaching here is an experimental idea to work around this issue without the maintenance burden of the quirks.

If anybody would be willing to test this patch, I would be very grateful.  To test it, either start with a v5.18 or earlier kernel, or on a v5.19 or newer kernel, revert d341838d776a (or just remove your system's ID from the list in pci_crs_quirks[]).  Then apply this patch, boot with the "efi=debug" parameter, connect a dock, see whether it works, and attach the dmesg log.
Comment 63 Benoit Grégoire 2022-11-21 20:40:04 UTC
I'd love to help you out Bjorn;  Unfortunately, I no longer have easy access to the original hardware.
Comment 64 Werner Sembach [TUXEDO] 2022-11-28 13:21:18 UTC
Tested on Clevo X170KM seems to work. Attached dmesg with dock attached during boot and dock attached after boot.
Comment 65 Werner Sembach [TUXEDO] 2022-11-28 13:22:36 UTC
Created attachment 303308 [details]
dmsg of experimental patch, dock attached before boot
Comment 66 Werner Sembach [TUXEDO] 2022-11-28 13:22:56 UTC
Created attachment 303309 [details]
dmsg of experimental patch, dock attached after boot
Comment 67 Bjorn Helgaas 2022-11-28 21:08:36 UTC
Created attachment 303314 [details]
add resource clip debug

Thank you very much, Werner!  I was confused about why your machine has DMI_BOARD_NAME "X170KM-G", but didn't match the quirk in d341838d776a ("x86/PCI: Disable E820 reserved region clipping via quirks"), but I see that in comment #62 I suggested reverting it, so I assume that's why I don't see "PCI: %s detected: not clipping E820 regions from _CRS" in your logs.

So the fact that it works as expected with the comment #62 patch but without the d341838d776a quirk is great news.

I do want to figure out the "clipped [mem size 0x00000000 64bit] to [mem size 0xfffffffffffa0000 64bit]" messages, which seem sort of bogus.  Can I trouble you to add this patch and attach the dmesg (from either dock scenario)?
Comment 68 Werner Sembach [TUXEDO] 2022-11-29 18:01:15 UTC
Created attachment 303326 [details]
dmsg of experimental patch, dock attached before boot 2
Comment 69 Werner Sembach [TUXEDO] 2022-11-29 18:01:39 UTC
Created attachment 303327 [details]
dmsg of experimental patch, dock attached after boot 2
Comment 70 Werner Sembach [TUXEDO] 2022-11-29 18:02:22 UTC
ofc uploaded the dmesg with the new patch
Comment 71 Konrad J Hambrick 2022-12-01 12:57:09 UTC
Bjorn --

Not to butt in, but ...

If you want it, I've built 6.0.10 with your Patches and I ran the same tests.

I've got a Sager NP9672M Laptop which is a rebranded Clevo X1170KM-G 

I've been working with Mika on Bug 214259 - Discrete Thunderbolt Controller 8086:1137 throws DMAR and XHCI errors and is only partially functional 

-- kjh
Comment 72 Bjorn Helgaas 2022-12-01 14:41:23 UTC
Hi Konrad, you're not butting in at all!

Things got a little tangled up here.  I think bug 214259 describes two issues:

1) Hot-added devices, e.g., an ethernet NIC in a dock, don't work.  This should be helped by https://git.kernel.org/linus/d341838d776a, which appeared in v5.19, but only for the machines specifically listed in that patch.

2) I/O page faults related to IOMMU and USB.  I think this one is still unresolved, and I don't think the comment #62 patch will help.

Your laptop is a rebranded Clevo.  Does it match the d341838d776a list?  You can tell by looking for "PCI: %s detected: not clipping E820 regions from _CRS" in your dmesg log.

If your laptop does not match the list, hot-added devices probably will not work with v6.0.  If the comment #62 patch makes them work better, that information would be extremely valuable.  A dmesg log from a boot with "pci=use_e820 efi=debug" would be very helpful.
Comment 73 Konrad J Hambrick 2022-12-01 15:03:36 UTC
Bjorn --

My Laptop does match d341838d776a

# dmesg  -t |grep DMI:
DMI: Notebook X170KM-G/X170KM-G, BIOS 1.07.08LS1 01/11/2020

I've already built 6.0.10 with your patches and I booted yesterday afternoon with these CommandLine Args:

ro nvidia-drm.modeset=1 thunderbolt.dyndbg=+p efi=debug loglevel=3 udev.log_level=3

Note that Mika gave me the thunderbolt.dyndbg=+p Arg and it does print some 'interesting but mysterious' info :)

I've already gatherred the two sets of logs, so ...

Q1:  Would you prefer a single .tgz file with the logs in sub-directories or do you prefer multiple attachments in this thread ?

Q2:  Would you prefer logs for linux 6.1-rc7 ?

I can build that one and gather logs for 6.1-rc7 instead of 6.0.y if you prefer.

Thanks again Bjorn !

-- kjh
Comment 74 Bjorn Helgaas 2022-12-01 15:51:15 UTC
Since your laptop does match d341838d776a, I don't think the comment #62 patch will make much difference.  It will likely change MMCONFIG messages from "reserved in E820" to "reserved in ACPI motherboard resources", but won't change the behavior.

No need to repeat with v6.1-rc7.  A single .tgz or even just the single dmesg log would be great.  I don't think lsmod/lspci/etc are relevant for this bug, but no harm in including them.
Comment 75 Konrad J Hambrick 2022-12-01 22:36:36 UTC
Created attachment 303339 [details]
6.0.10 Logs

Bjorn --

Attached anker-tests-e..f-tar.gz 

Manifest is below.

I went ahead and included all the logs I had already gathered yesterday after reading this thread.

Notable:

1. The Patches I applied are in kernel_config_debug/linux-6.0.10.kjh_dp.patch

2. Test(e) - Boot with Thunderbolt Attached ...

Read Performance dropped from ~800 MB/sec to 39 MB/sec hdparm after unplugging then replugging the TBT

This did not happen when I booted with TBT unplugged ...

Thank You !

-- kjh

Manifest of anker-tests-e..f-tar.gz in temporal order:

kernel_config_debug/

   .config
   linux-6.0.10.kjh_dp.patch

test-e-with-tbt4-on-at-boot-thunderbolt-debug/

   dmesg-boot-with-tbt4-on.txt
   lsusb-vv-boot-with-tbt4-on.txt
   lsmod-boot-with-tbt4-on.txt
   lspci-vv-boot-with-tbt4-on.txt
   hdparm--direct-t_sda3-boot-with-tbt4-on.txt

   dmesg-boot-with-tbt4-on-unplugged.txt
   lsusb-vv-boot-with-tbt4-on-unplugged.txt
   lspci-vv-boot-with-tbt4-on-unplugged.txt
   lsmod-boot-with-tbt4-on-unplugged.txt

   dmesg-boot-with-tbt4-on-replugged.txt
   lsmod-boot-with-tbt4-on-replugged.txt
   lspci-vv-boot-with-tbt4-on-replugged.txt
   hdparm--direct-t_sda3-boot-with-tbt4-on-replugged.txt
   lsmod-boot-with-tbt4-on-replugged-after-hdparm.txt

test-f-without-tbt4-on-at-boot-thunderbolt-debug/

   dmesg-boot-without-tbt4-on.txt
   lspci-vv-boot-without-tbt4-on.txt
   lsusb-vv-boot-without-tbt4-on.txt
   lsmod-boot-without-tbt4-on.txt

   dmesg-boot-without-tbt4-on-plugged.txt
   lsmod-boot-without-tbt4-on-plugged.txt
   lspci-vv-boot-without-tbt4-on-plugged.txt
   lsusb-vv-boot-without-tbt4-on-plugged.txt
   hdparm--direct-t_sda3-boot-without-tbt4-on-plugged.txt

   dmesg-boot-without-tbt4-on-unplugged.txt
   lsmod-boot-without-tbt4-on-unplugged.txt
   lspci-vv-boot-without-tbt4-on-unplugged.txt
   lsusb-vv-boot-without-tbt4-on-unplugged.txt

   dmesg-boot-without-tbt4-on-replugged.txt
   lsmod-boot-without-tbt4-on-replugged.txt
   lspci-vv-boot-without-tbt4-on-replugged.txt
   lsusb-vv-boot-without-tbt4-on-replugged.txt
   hdparm--direct-t_sda3-boot-without-tbt4-on-replugged.txt
Comment 76 Bjorn Helgaas 2022-12-01 23:33:25 UTC
Thanks for those!  It's a little overwhelming, but I don't see any issues related to the comment #62 patch.  It seems to work as I expect on your system.

There are definitely dock hotplug issues and the performance issue, but those are problems for different reports.
Comment 77 Konrad J Hambrick 2022-12-02 09:25:14 UTC
Yes, it is overwhelming, isn't it.

The only thing that seems to stick out for me is when I sdiff pairs of lsmod and lsusb files where it seems like the states of the devices should return to the initial states after plugging or unplugging the TBT4 Dock.

For example, when I sdiff these two files, there are just a few diffs in the TBT-related Flags:

test-f-without-tbt4-on-at-boot-thunderbolt-debug/lspci-vv-boot-without-tbt4-on.txt
test-f-without-tbt4-on-at-boot-thunderbolt-debug/lspci-vv-boot-without-tbt4-on-unplugged.txt

It seems that these two files should show the TBT PCI Devices in the same state ?

But it's been almost 40 years since I messed with any low level PeeCee firmware programming and I am just a tad behind the times :)

Anyhow, thanks for what you ( and all the Kernel Devs ) do !

I appreciate you !!

-- kjh
Comment 78 Konrad J Hambrick 2022-12-02 09:27:56 UTC
p.s. Yes Bjorn, your patch from commentt #62 worked perfectly, even after I removed the Clevo Entry from the pci_crs_quirks[] array.
Comment 79 Jonas Ryssel 2023-01-01 19:34:57 UTC
Thanks for the great work!

Hotplugging thunderbolt docks definitely work better, but I still have a couple issues.

Before I start, here is some info about my setup.

I use KDE on Arch Linux, but it shouldn't affect the problem. uname -a prints: 
Linux MyPC 6.1.1-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 21 Dec 2022 22:27:55 +0000 x86_64 GNU/Linux

Regarding BIOS, I am running the non-standard Lenovo C940 BIOS that some Lenovo engineer temporarily released on their forum to fix the speakers on Linux (version AUCN57WW).

My dock is a "Kensington SD5500T/SD5550T Thunderbolt 3 and USB-C Docking Station".

But now to the issues.

First: The fix currently mainlined in the kernel doesn't work for me. After comparing the file arch/x86/pci/acpi.c on github with the result of dmidecode (see below), I think it the check for DMI_PRODUCT_VERSION should be changed to checking the product family. It could potentially be related to my non-standard BIOS version, but I can't check that.

Second: Since the current fix didn't apply to my computer, I tried compiling the kernel myself and applying the patch from comment #62.
My dock has both a USB hub and display outputs, and on the non-patched kernel, if I tried hotplugging it, the USB hub didn't work, but the external displays always did (and sometimes the computer crashed).
On the patched kernel, if I hotplug, the USB hub always works, and I haven't experienced any crashes, but the external displays aren't recognized. More specifically, if the dock is unplugged when booting and I then hotplug it, they aren't recognized. If instead the computer is docked while booting, the displays work, and if I unplug the dock and then replug it within ~5-10 seconds, the displays are recognized again. If I instead have the dock unplugged for a minute or so, the displays are not recognized when replugging the dock.
I have tried running lspci -vv, and the output differs between if the computer was docked on boot and after it was un- and replugged, but it doesn't differ between if the external displays are recognized or not.

I would attach dmesg and lspci -xxxx, but I cannot figure out how to create attachments, so please help me if you need that info. And please specify under which conditions you want the logs. :)

--- dmidecode ---
Handle 0x0001, DMI type 1, 27 bytes
System Information
        Manufacturer: LENOVO
        Product Name: 81Q9
        Version: Yoga C940
        Serial Number: [...]
        UUID: [...]
        Wake-up Type: Power Switch
        SKU Number: LENOVO_MT_81Q9_BU_idea_FM_Yoga C940-14IIL
        Family: Yoga C940-14IIL
Comment 80 Bjorn Helgaas 2023-01-03 21:06:59 UTC
Thanks, Jonas.  This bugzilla has a lot of stuff going on, and it's not clear yet whether the issue you're seeing is the same, so can you please open a new report?

Use the "File a Bug" button at https://bugzilla.kernel.org/ and the Drivers/PCI product/component.  After you open the issue, the "Add an attachment" link is near the top of the issue, just above your "Description".  Make the attachments text/plain.

If you can attach a complete dmesg log and output of "sudo lspci -vv", that would be great.  Since you can compile your own kernel, testing with v6.2-rc1 would be a great place to start.  It includes the equivalent of the comment #62 patch, so I expect you'll see the display issues.  I would start with "boot undocked, collect lspci, dock, collect lspci, collect dmesg".
Comment 81 Jonas Ryssel 2023-01-16 08:38:02 UTC
First of all, I forgot that this issue was for "thinkpad thunderbolt 3 dock gen2" specifically. Sorry.

Anyway, I leave this as a note for other people who came here from the Arch Linux wiki: The mainline kernel (6.2-rc2) works without bugs (in my case). I have been testing it for a week, and I haven't had a single issue.

Basically, either one of these things was the problem:
1. I messed up when applying the patch. :P
2. The Arch Linux 6.1 kernel has some other patch that interferes with the patch from comment #62 and causes my problems.
3. Something other than the patch from comment #62 has been introduced in the 6.2-rc1(/2), which helps fix the bug.

I don't know which one is the problem, but this doesn't seem to be an issue for the mainline kernel. I am sorry for the confusion.