4 ms·
As user I would just return the device back and purchase a reliable USB based device. As a Mac-user would do? I guess a Windows-User would just rate [1/5] sta
by ho_schi 4y ago
As user I would just return the device back and purchase a reliable USB based device.
As a Mac-user would do?
I guess a Windows-User would just rate [1/5] stars and don't even research.
We should keep in mind:
Linux users care a lot and do research. Most other will just say "nope" and leave it a issue for the manufacturer or keep turning it off and on again. What I don't know is if the initial situation is to blame upon Linux, Intel (Thunderbolt), device manufacturer or all of them. We have valuable post a the top explaining PCIe-Pause on MacOS and that Linux tries to apply a similar mitigation?
Apple:
Because Thunderbolt allows the addition and removal of arbitrary numbers of peripherals connected in arbitrary topologies, the task of dividing up the PCI tree’s address space can be challenging. Sometimes, particularly when large numbers of devices are attached, it is possible to exhaust portions of that address space. When this happens, a new device cannot be enabled without moving existing devices.
To solve this problem, OS X v10.9 supports PCIe Pause—a special power management state in which all driver and device operations are temporarily suspended. Whenever address space exhaustion occurs, OS X may ask drivers to pause operations. After the drivers are paused, OS X changes the address space layout of the paused devices to make room for new devices, and then tells the drivers to resume normal operation
Oh.
If your driver does not explicitly declare support for pausing, your driver will never receive pause requests. As a result, devices may fail to appear when the user plugs in additional devices, particularly on hardware with multiple Thunderbolt ports. For this reason, you are strongly encouraged to support this functionality as soon as possible.
Ouch. On Linux this shouldn't be an big issue because the kernel provides them.
From the mentioned Linux patches:
Currently PCI hotplug works on top of resources which are usually reserved:
by BIOS, bootloader, firmware, or by the kernel (pci=hpmemsize=XM). These resources are gaps in the address space where BARs of new devices may fit, and extra bus number per port, so bridges can be hot-added. This series aim the BARs problem: it shows the kernel how to redistribute them on the run, so the hotplug becomes predictable and cross-platform.
Fits into what Apple describes. The patch for Linux would be helpful. And I've the feeling that the approach Intel has chosen to add TB upon PCIE isn't bulletproof?
- oneplane 4y agoI don't think that really fits together. PCIe (and PCI) hotplug has existed for a while and topology changes aren't new either. ExpressCard for example has done this, as has PCMCIA. Older RDMA buses did this too, as do backplane-based industrial PCs of which there are a really large amount. I suspect that end-user smoothness based on 'the user is not required to know everything' that makes the likes of Apple implement bus pausing for dynamic topology assignment and BAR adjustment is not available in Linux land because there simply isn't a big enough overlap of people to make this a hot topic. You need: 1. A person who understands how this works 2. A person who understands what they want to use it for 3. A person who understands what person 1 has to do so person 2 can use it Usually you get 1 or 2, sometimes both, but almost never 3 except at places like Canonical, RedHat, SuSE etc. because it's too much of an analyst role and not enough of a "I need it for myself and I can build it" role. Similar but different problems exist in other software areas like when person "3" is split in "business", "end-user" and "licensing" with competing interests. That's where you get the NT kernel which gets split into arbitrary partitions where based on an integer configuration it may or may not want to address your RAM. Same goes for the old "aperture size" for GPU memory transfers, and later on the BAR resize support. It was never 'hard' to implement, it's just that IBV's didn't bother and mainboard manufacturers didn't care. Yet it was always available and even Tianocore EDK2, Apple's own EFI and (for some reason) BIOS and UEFI from Quanta and Supermicro all did support it just fine. Same goes for KMS and non-blink GPU switchovers where AMD, NVDA and Intel used to constantly sell it as 'impossible' and we all just accepted that. Yet KMS, the MobileFramebuffer (and the old AppleTV Gen 1) and even VesaFB showed that it's totally possible and it's just everyone using the same joke sample implementation from the vendor that's causing it. Another example would be VESA where DisplayPort topology changes on the control channel side do similar things to PCIe bus pausing. The display controllers and bus drivers should pause on hot plug to let the host decide on the new topology, but implementing that costs time and effort, and you need to have some in-depth knowledge on both the hardware and software side, so lots of companies don't bother. Result: some host+display combinations only work after restarting either end to force it to re-discover the current topology. This even happens in 1:1 topology scenarios where a simple GPU driver update might restart the host bus and the display ignores it and simply stops receiving data until the watchdog timer restarts the embedded processor causing the screen to blink. I'd just dumb low-quality choices and corner-cutting that causes this.
- bombcar 4y agoI wonder if this is why some of my monitors don't come back on after sleep. Is there a way to tell if macOS did the pause via the logs?