Launchpad has imported 54 comments from the remote bug at https://bugzilla.kernel.org/show_bug.cgi?id=206459.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2020-02-07T19:52:30+00:00 benoitg wrote: Created attachment 287231 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/12 ------------------------------------------------------------------------ On 2020-02-07T19:54:07+00:00 benoitg wrote: Created attachment 287233 mainline_5.5.2_notworking_dmesg_dock_plugged_after_boot Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/13 ------------------------------------------------------------------------ On 2020-02-07T19:54:41+00:00 benoitg wrote: Created attachment 287235 mainline_5.5.2_notworking_lspci_vvvv_dock_plugged_after_boot Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/14 ------------------------------------------------------------------------ On 2020-02-07T19:55:04+00:00 benoitg wrote: Created attachment 287237 mainline_5.5.2_notworking_lsusb_dock_plugged_after_boot Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/15 ------------------------------------------------------------------------ On 2020-02-07T19:55:24+00:00 benoitg wrote: Created attachment 287239 mainline_5.5.2_working_dmesg_dock_plugged_before_boot Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/16 ------------------------------------------------------------------------ On 2020-02-07T19:55:46+00:00 benoitg wrote: Created attachment 287241 mainline_5.5.2_working_lspci_vvvv_dock_plugged_before_boot Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/17 ------------------------------------------------------------------------ On 2020-02-07T19:56:10+00:00 benoitg wrote: Created attachment 287243 mainline_5.5.2_working_lsusb_dock_plugged_before_boot Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/18 ------------------------------------------------------------------------ On 2020-02-17T21:21:44+00:00 benoitg wrote: Still no luck on 5.5.4, and with an updated BIOS (AUCN54WW) Is there any other information I could provide? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/22 ------------------------------------------------------------------------ On 2020-02-18T00:27:45+00:00 nicholas.johnson-opensource wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/24 ------------------------------------------------------------------------ On 2020-02-18T07:43:59+00:00 mika.westerberg wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/25 ------------------------------------------------------------------------ On 2020-02-18T18:09:49+00:00 benoitg wrote: Created attachment 287469 mainline_5.6rc2_working_dmesg_dock_plugged_before_boot Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/26 ------------------------------------------------------------------------ On 2020-02-18T18:10:56+00:00 benoitg wrote: Created attachment 287471 mainline_5.6rc2_working_lspci_xxxx_dock_plugged_before_boot Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/27 ------------------------------------------------------------------------ On 2020-02-18T18:11:50+00:00 benoitg wrote: Created attachment 287473 mainline_5.6rc2_working_lspci_vt_dock_plugged_before_boot Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/28 ------------------------------------------------------------------------ On 2020-02-18T18:12:25+00:00 benoitg wrote: Created attachment 287475 mainline_5.6rc2_reference_lspci_vv_dock_not_plugged Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/29 ------------------------------------------------------------------------ On 2020-02-18T18:12:48+00:00 benoitg wrote: Created attachment 287477 mainline_5.6rc2_reference_dmesg_dock_not_plugged Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/30 ------------------------------------------------------------------------ On 2020-02-18T18:13:58+00:00 benoitg wrote: Created attachment 287479 mainline_5.6rc2_notworking_lspci_vv_dock_plugged_second_port_after_boot Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/31 ------------------------------------------------------------------------ On 2020-02-18T18:14:40+00:00 benoitg wrote: Created attachment 287481 mainline_5.6rc2_notworking_dmesg_dock_plugged_second_port_after_boot Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/32 ------------------------------------------------------------------------ On 2020-02-18T18:15:12+00:00 benoitg wrote: Created attachment 287483 mainline_5.6rc2_notworking_dmesg_dock_plugged_after_boot Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/33 ------------------------------------------------------------------------ On 2020-02-18T18:15:38+00:00 benoitg wrote: Created attachment 287485 mainline_5.6rc2_notworking_dmesg_dock_replugged_after_boot Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/34 ------------------------------------------------------------------------ On 2020-02-18T18:19:48+00:00 benoitg wrote: 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! Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/35 ------------------------------------------------------------------------ On 2020-02-19T02:38:12+00:00 nicholas.johnson-opensource wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/36 ------------------------------------------------------------------------ On 2020-02-19T03:01:33+00:00 nicholas.johnson-opensource wrote: Benoit, are you comfortable compiling and running your own kernel? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/37 ------------------------------------------------------------------------ On 2020-02-19T03:05:34+00:00 benoitg wrote: Created attachment 287493 mainline_5.6rc2_working_dmesg_pci_dyndbg_dock_plugged_before_boot Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/38 ------------------------------------------------------------------------ On 2020-02-19T03:06:04+00:00 benoitg wrote: Created attachment 287495 mainline_5.6rc2_working_lspci_vnnt_dock_plugged_before_boot Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/39 ------------------------------------------------------------------------ On 2020-02-19T03:09:38+00:00 benoitg wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/40 ------------------------------------------------------------------------ On 2020-02-19T03:11:51+00:00 nicholas.johnson-opensource wrote: 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/psxp216mb0438be9da58d0af9f908070680...@psxp216mb0438.korp216.prod.outlook.com/T/ Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/41 ------------------------------------------------------------------------ On 2020-02-19T03:13:58+00:00 nicholas.johnson-opensource wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/42 ------------------------------------------------------------------------ On 2020-02-19T04:19:32+00:00 benoitg wrote: Created attachment 287501 mainline_5.6rc2_notworking_dmesg_pci_dyndbg_dock_plugged_after_boot Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/43 ------------------------------------------------------------------------ On 2020-02-19T04:20:08+00:00 benoitg wrote: Sure, see new attachment Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/44 ------------------------------------------------------------------------ On 2020-02-19T05:36:02+00:00 nicholas.johnson-opensource wrote: 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! Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/45 ------------------------------------------------------------------------ On 2020-02-19T05:40:05+00:00 nicholas.johnson-opensource wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/46 ------------------------------------------------------------------------ On 2020-02-19T05:43:29+00:00 nicholas.johnson-opensource wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/47 ------------------------------------------------------------------------ On 2020-02-19T06:46:09+00:00 benoitg wrote: Created attachment 287503 mainline_5.6rc2_cat_proc_iomem_before_attach Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/48 ------------------------------------------------------------------------ On 2020-02-19T06:47:31+00:00 benoitg wrote: Created attachment 287505 mainline_5.6rc2_cat_proc_iomem_after_attach Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/49 ------------------------------------------------------------------------ On 2020-02-19T06:48:20+00:00 benoitg wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/50 ------------------------------------------------------------------------ On 2020-02-19T08:36:32+00:00 mika.westerberg wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/51 ------------------------------------------------------------------------ On 2020-02-19T08:52:30+00:00 mika.westerberg wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/52 ------------------------------------------------------------------------ On 2020-02-19T18:28:05+00:00 benoitg wrote: Created attachment 287511 mainline_5.6rc2_working_dmesg_pci_dyndbg_dock_plugged_before_boot Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/53 ------------------------------------------------------------------------ On 2020-02-19T18:28:38+00:00 benoitg wrote: Created attachment 287513 mainline_5.6rc2_notworking_dmesg_pci_dyndbg_dock_plugged_after_boot Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/54 ------------------------------------------------------------------------ On 2020-02-19T18:29:56+00:00 benoitg wrote: Ok, thanks Mika. I compiled my own kernel and the attachments above now have the information Nicholas wanted. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/55 ------------------------------------------------------------------------ On 2020-02-20T09:03:51+00:00 mika.westerberg wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/56 ------------------------------------------------------------------------ On 2020-02-21T00:41:36+00:00 benoitg wrote: Created attachment 287523 mainline_5.6rc2_notworking_dmesg_pci_dyndbg_dock_plugged_after_boot_hpmensize_0 Attempt with pci=hpmemsize=0 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/57 ------------------------------------------------------------------------ On 2020-02-21T09:46:49+00:00 mika.westerberg wrote: Created attachment 287533 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/58 ------------------------------------------------------------------------ On 2020-02-22T05:03:18+00:00 benoitg wrote: Created attachment 287551 mainline_5.6rc2_notworking_dmesg_dock_plugged_after_boot_2020-02-21_patch Unfortunately, the patch did not help Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/59 ------------------------------------------------------------------------ On 2020-02-25T13:45:15+00:00 mika.westerberg wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/60 ------------------------------------------------------------------------ On 2020-02-25T19:23:27+00:00 benoitg wrote: That's great news for me! Thanks a lot Mika, and good luck... Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/61 ------------------------------------------------------------------------ On 2020-02-26T15:37:39+00:00 mika.westerberg wrote: Created attachment 287619 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/62 ------------------------------------------------------------------------ On 2020-02-27T14:23:53+00:00 mika.westerberg wrote: Created attachment 287661 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/63 ------------------------------------------------------------------------ On 2020-02-27T15:04:55+00:00 nicholas.johnson-opensource wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/64 ------------------------------------------------------------------------ On 2020-02-27T18:30:53+00:00 benoitg wrote: Created attachment 287663 mainline_5.6rc3_working_dmesg_dock_plugged_after_boot_patch_287619 Result of trying patch 287619, it works! Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/65 ------------------------------------------------------------------------ On 2020-02-27T18:31:55+00:00 benoitg wrote: Created attachment 287665 mainline_5.6rc3_working_dmesg_dock_plugged_after_boot_patch_287661 Result of trying patch 287661, it ALSO works! Many thanks! Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/66 ------------------------------------------------------------------------ On 2020-03-02T15:05:39+00:00 mika.westerberg wrote: Great, thanks for testing. I submitted the patch upstream now: https://lore.kernel.org/lkml/20200302141451.18983-1-mika.westerb...@linux.intel.com/ Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/68 ------------------------------------------------------------------------ On 2020-03-02T15:07:51+00:00 mika.westerberg wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/69 ------------------------------------------------------------------------ On 2020-06-16T22:26:34+00:00 benoitg wrote: Any chance this will make it into 5.8 ? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860284/comments/70 ** Changed in: linux Status: Unknown => Confirmed ** Changed in: linux Importance: Unknown => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1860284 Title: thinkpad thunderbolt 3 dock gen2 with pci memory allocation errors on Yoga C940 unless plugged in before boot To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1860284/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
