Thank you for the insights, Heikki! Please find the acpi.dump.tgz file is a attached. I do not have the USBC* and INT3515* devices, so I have attached the following file as well: # ls -1 /sys/bus/acpi/devices/*/status | while read dev; do echo $dev: $(cat $dev); done | gzip -c > /tmp/all-device-status.log.gz KR, Andrey Arapov April 10, 2018 4:35 PM, "Heikki Krogerus" <heikki.krogerus@xxxxxxxxxxxxxxx> wrote: > On Tue, Apr 10, 2018 at 09:05:07AM +0000, andrey.arapov@xxxxxxxxxx wrote: > >> Dear Linux Kernel Devs, >> >> I have recently got a Lenovo ThinkVision X1 27" monitor, it is connected to my >> laptop over a USB-C cable (DisplayPort). >> >> This monitor has a built-in USB hub with a toggle button, when pressed it >> shows two options on the screen: >> >> Press USB Switch to toggle between: >> A) 3840x2160 UHD USB 2.0 >> B) 1920x1080 FHD USB 3.0 >> >> By default it is always set to FHD, which is why Linux sees the 1920x1080 as a >> maximum possible resolution. >> >> Whenever I am changing it to the UHD, Linux is not changing the resolution to >> 3840x2160, instead it sets to somewhere around 2560x####. >> >> To work this around, I am running the following commands manually: >> >> xrandr --newmode "3840x2160_60.00" 533.25 3840 3888 3920 4000 2160 2163 2168 2222 +hsync -vsync >> xrandr --addmode DisplayPort-2 3840x2160_60.00 >> xrandr --output DisplayPort-2 --mode 3840x2160_60.00 >> >> Then, when I was trying to switch it back to FHD and again back to UHD, >> sometimes it causes a kernel panic. The panic also happened when I was >> plugging the cable in/out and back again. What I was able to spot is that the >> last unloaded kernel module was usbhid. >> >> Please advise, what can I try to help investigating this issue further? >> >> I have attached the output from "dmesg -T" command as "4.16.1-dmesg.txt" file. >> The logs are related to when the monitor was connected via a USB-C cable to a >> DisplayPort-2, the default resolution picked was FHD (USB 3.0) and then I have >> pressed the toggle button to use UHD (USB 2.0), then have applied the "xrandr" >> commands and have closed the lid of my laptop so I would be using my monitor >> as a primary display. > > The board seems to support Thunderbold, however, in this case my guess is that > the monitor is actually using just the DP alternate mode (Thundebolt can pipe > DisplayPort protocol). > > I'm guessing the problem is related to the DisplayPort lane counts. With the > highest resolutions you need all four lanes, but if you want to use USB3 with > USB Type-C connectors at the same time, two have to be allocated for USB3 > leaving only two for DisplayPort allowing lower resolution. The problem is that > the GPU drivers need to know how many lanes the DisplayPort has in use. That > information will in normal case come from USB Type-C drivers. Unfortunately we > do not have support for that in Linux kernel yet, but I have made a proposal for > a solution. > > Let's start by checking details of your board. Can you send us acpidump output? > > % acpidump -o <filename> > > Also, please check the status of these acpi devices: > > % cat /sys/bus/acpi/devices/USBC*/status > % cat /sys/bus/acpi/devices/INT3515*/status > > Br, > > -- > heikki
Attachment:
acpi.dump.tgz
Description: GNU Zip compressed data
Attachment:
all-device-status.log.gz
Description: GNU Zip compressed data
