On Thu, 14 Nov 2024 13:51:36 +0200 Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > Hi Aaron, > > On Tue, Nov 12, 2024 at 04:44:47PM -0500, Aaron Rainbolt wrote: > > On Mon, 11 Nov 2024 10:22:23 +0200 > > Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > > > > > Hi, > > > > > > On Thu, Nov 07, 2024 at 11:45:44AM +0200, Mika Westerberg wrote: > > > > Hi, > > > > > > > > On Wed, Nov 06, 2024 at 11:01:34AM -0600, Aaron Rainbolt wrote: > > > > > > > > > > Unfortunately that does not help here. I need to figure > > > > > > something else how to detect the redrive case with this > > > > > > firmware but first, does this work in Windows? I mean if you > > > > > > install Windows to this same system does it work as > > > > > > expected? > > > > > > > > > > It does work as expected under Windows 11, with one major > > > > > caveat. We used a Windows 11 ISO with a setup.exe created on > > > > > April 05 2023 for installing the test system, and after > > > > > initial installation it behaved exactly the same way as Linux > > > > > behaves now (displays going blank soon after being plugged > > > > > in). However, after installing all available Windows updates, > > > > > the issue resolved, and the displays worked exactly as > > > > > intended (the screens are recognized when attached and do not > > > > > end up disconnecting after a timeout). > > > > > > > > > > Would it be helpful to test on Windows 11, and provide a > > > > > report and system logs? > > > > > > > > Unfortunately, I don't know anything about Windows ;-) > > > > > > > > However, I asked our Thunderbolt hardware/firmware team about > > > > this, if they have any idea how it was solved in Windows side. > > > > Might take a couple of days though. > > > > > > While waiting for this, I wonder if you guys could do one more > > > experiment? I would like to get the traces what is happening there > > > (hoping something pops out there). Following steps: > > > > > > 1. Download and install tbtools [1]. > > > 2. Build and install the kernel with my "redrive" patch. > > > 3. Boot the system up, nothing connected. > > > 4. Wait until the Barlow Ridge is in runtime suspend (so wait > > > for ~30s or so) > > > 5. Enable tracing: > > > > > > # tbtrace enable > > > > > > 6. Plug in USB-C monitor to the USB-C port of the Barlow Ridge. > > > Do not run 'lspci -k'. Expectation here is that there is no > > > picture on the monitor (in other words the issue reproduces). > > > > > > 7. Stop tracing and take full dump: > > > > > > # tbtrace disable > > > # tbtrace dump -vv > trace.out > > > > > > 8. Send trace.out along with full dmesg to me. > > > > > > Thanks! > > > > > > [1] https://github.com/intel/tbtools > > > > Testing done as requested. Notes from tester: > > Thanks! > > > * I verified lsmod |grep thunderbolt which showed module. > > * When running sudo ./tbtrace enable, output was Thunderbolt/USB4 > > tracing: Enabled. > > * When plugging in monitor, it wakes the backlight, but there is no > > image. syslog shows it as LG monitor controls. The monitor reports > > "no signal" and eventually turns off the backlight to save power. > > * When running sudo ./tbtrace disable, output was Thunderbolt/USB4 > > tracing: Disabled. > > * Output was save using tbtrace dump -vv > trace.out and sudo dmesg > > > trace.dmesg. trace.out is an empty file. > > > > --- > > > > (Yes, that's correct, trace.out is empty. I attached it nonetheless, > > but it's a 0-byte file. I'm guessing the Thunderbolt chip probably > > didn't come out of suspend?) > > Yes, that's possible and this could explain the Linux behaviour but it > does not explain why it works in Windows. Also the dmesg is full of > stacktraces, not much else. > > I got reply from our experts. They say that we are expected to get the > DP IN unplugs every single time we enter redrive mode. There is > nothing "special" added to the Windows side for this either so there > is no real explanation why it works in Windows and why we see this in > Linux. What they also wanted to check is that with the "production > quality" Barlow Ridge firmwares this is not expected to happen and > yours is in 14.x so is this some pre-production hardware that you are > dealing with or this can be purchased from somewhere? Where did you > get the firmware? This is production hardware (specifically Clevo's X370SNW1-G and X370SNV1-G laptops), available for purchase from Sager, XOTICPC, Schenker, likely many other resellers, and our own website at https://kfocus.org/spec/spec-m2.html (with a tool that allows users to work around the bug). The firmware is baked into the hardware provided to us by our ODM, and for the sake of stability we do not modify any firmware on the machines with the exception of applying BIOS updates provided to us directly by the ODM. They appear to get their firmware directly from Clevo. We have requested an updated BIOS from the ODM. If one is available, we will upgrade and run the tests again. Thanks again for your help! Aaron > Thanks!
