Created attachment 287231 [details]
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
- 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:
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
Created attachment 287233 [details]
Created attachment 287235 [details]
Created attachment 287237 [details]
Created attachment 287239 [details]
Created attachment 287241 [details]
Created attachment 287243 [details]
Still no luck on 5.5.4, and with an updated BIOS (AUCN54WW)
Is there any other information I could provide?
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.
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?
Created attachment 287469 [details]
Created attachment 287471 [details]
Created attachment 287473 [details]
Created attachment 287475 [details]
Created attachment 287477 [details]
Created attachment 287479 [details]
Created attachment 287481 [details]
Created attachment 287483 [details]
Created attachment 287485 [details]
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!
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.
Benoit, are you comfortable compiling and running your own kernel?
Created attachment 287493 [details]
Created attachment 287495 [details]
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.
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?):
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
Created attachment 287501 [details]
Sure, see new attachment
It does not contain the information I am expecting.
I need to see the pci_dbg() calls at lines 1855 and 1859 here:
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"?
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.
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
Created attachment 287503 [details]
Created attachment 287505 [details]
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.
(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.
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.
Created attachment 287511 [details]
Created attachment 287513 [details]
Ok, thanks Mika. I compiled my own kernel and the attachments above now have the information Nicholas wanted.
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.
Created attachment 287523 [details]
Attempt with pci=hpmemsize=0
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.
Created attachment 287551 [details]
Unfortunately, the patch did not help
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.
That's great news for me! Thanks a lot Mika, and good luck...
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.
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.
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.
Created attachment 287663 [details]
Result of trying patch 287619, it works!
Created attachment 287665 [details]
Result of trying patch 287661, it ALSO works! Many thanks!
Great, thanks for testing. I submitted the patch upstream now:
(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.
Any chance this will make it into 5.8 ?
I just resent the patch. Hopefully it lands mainline at some point :)