linux-kernel - Re: USB-C DisplayPort display failing to stay active with Intel Barlow Ridge USB4 controller, power-management related issue?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241114115136.GB3187799@black.fi.intel.com>
Date: Thu, 14 Nov 2024 13:51:36 +0200
From: Mika Westerberg <mika.westerberg@...ux.intel.com>
To: Aaron Rainbolt <arainbolt@...cus.org>
Cc: YehezkelShB@...il.com, michael.jamet@...el.com,
	andreas.noever@...il.com, linux-usb@...r.kernel.org,
	mmikowski@...cus.org, linux-kernel@...r.kernel.org,
	Gil Fine <gil.fine@...ux.intel.com>
Subject: Re: USB-C DisplayPort display failing to stay active with Intel
 Barlow Ridge USB4 controller, power-management related issue?

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@...ux.intel.com> 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?

Thanks!