The minimum I can use to reproduce the fault is a single Thunderbolt display. I've left in the patch to not set up the DP tunnel and recompiled with CONFIG_PCI_DEBUG=y > get me the full dmesg output (with CONFIG_PCI_DEBUG=y) and output of > Is it possible to narrow this down to a single device connected and then > and the TBT driver should block it too. > Thunderbolt 1 devices there is really no PM we can do for them at all > parameter should prevent that from happening. > afterwards sounds exactly like that the runtime PM would kick in but the > "pcie_port_pm=off" in the kernel command line? > that appears after the OS is booted up. > Okay, let's try to deal with one issue at the time so first the hang > If I do an lspci -tv after the module load, it locks hard instantly and reproducibly. > had a chance to finish it because I attempted to verify the devices were present with an lspci -tv. > up on reboot and the first time I attempted to compose this reply it locked up hard before I None of the TB displays light up in Linux or BIOS. > tb_dbg(tb, "DP tunneling disabled, not creating tunnel\n") > iff -git a/drivers/thunderbolt/tb.c b/drivers/thunderbolt/tb.c Alternatively you can try to comment out the call to > to disable the tunneled DP connections and see if that makes it not > Not sure if it is possible (I think it is from sysfs /sys/class/drm/*) > They are pretty standard so I suspect myself the display side of things.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |