dri-devel September 2019

dri-devel@lists.freedesktop.org

315 participants
2278 discussions

[Bug 48215] New: [NV11] Display constantly switches on and off roughly every 10 seconds.
by bugzilla-daemon＠freedesktop.org 14 Oct '19

14 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=48215 Bug #: 48215 Summary: [NV11] Display constantly switches on and off roughly every 10 seconds. Classification: Unclassified Product: DRI Version: XOrg CVS Platform: x86 (IA32) OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/other AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: alex.buell(a)munted.org.uk Display constantly switches on and off roughly every 10 seconds on my NV11 machine. This started happening with 3.2.0. Checking backwards, 3.1.0 works just fine. I am currently trying a bisect to find the problem. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 2

[Bug 52560] New: Xorg -configure creats useless xorg.conf for tdfx
by bugzilla-daemon＠freedesktop.org 14 Oct '19

14 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=52560 Bug #: 52560 Summary: Xorg -configure creats useless xorg.conf for tdfx Classification: Unclassified Product: DRI Version: XOrg CVS Platform: All OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/other AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: tuxracer(a)hispeed.ch Had want to install my old Voodoo3/2000 PCI that 2 or 3 years ago perfectly work. Now on actual xorg-server at least 1.10 1.11 1.12 I really unable to configure a working 3D. If i use the driver without any xorg.conf I can use at least Software-Rendering. But if i create a xorg.conf using Xorg -configure it gives no 3D. On old xorg-servers the only thing i had to do for 3D on this card was to set the resolution to 1024x768 at 16bit colordepth and it worked. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 3

[Bug 38364] New: Ignoring invalid EDID block 1 do entire edid is invalid and not just block 1
by bugzilla-daemon＠freedesktop.org 14 Oct '19

14 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=38364 Summary: Ignoring invalid EDID block 1 do entire edid is invalid and not just block 1 Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: All Status: NEW Severity: normal Priority: medium Component: General AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: zaverel(a)free.fr Hello , All is fine except i can't change resolution on my second monitor vga ,tv in fact, (reported as DVI-I-2 ) anymore with my 9400gt. Now , i'm on : linux-2.6.39-gentoo-r1 xorg-server-1.10.2 xf86-video-nouveau-0.0.16_pre20110323 libdrm-2.4.25 Errors in dmesg are: nouveau 0000:02:00.0: DVI-I-2: Ignoring invalid EDID block 1. [drm:drm_edid_block_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ whatever i valid with xrandr is not really do on my tv although xrandr say it's good , my tv always report 1202x670 50hz I tried with and without xorg.conf My last kernel working is linux-2.6.36-gentoo-r6. If, i tweak drm_edid.c from kernel-2.6.39-gentoo-r1 like this: --- drm_edid.c 2011-06-10 22:37:36.605848000 +0200 +++ linux/drivers/gpu/drm/drm_edid.c 2011-06-13 13:04:43.136786102 +0200 @@ -292,7 +292,7 @@ block + (valid_extensions + 1) * EDID_LENGTH, j, EDID_LENGTH)) goto out; - if (drm_edid_block_valid(block + (valid_extensions + 1) * EDID_LENGTH)) { + if (drm_edid_block_valid(block + (valid_extensions + 0) * EDID_LENGTH)) { valid_extensions++; break; } that work good like before but i'm not sure that is safe. More info in http://lists.freedesktop.org/archives/nouveau/2011-June/008548.html I can post logs here too , just tell me. See you -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 1

[Bug 105235] shutdown gives a NMI and locks (nouveau?)
by bugzilla-daemon＠freedesktop.org 14 Oct '19

14 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=105235 Bug ID: 105235 Summary: shutdown gives a NMI and locks (nouveau?) Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/other Assignee: dri-devel(a)lists.freedesktop.org Reporter: conde.philippe(a)skynet.be Created attachment 137579 --> https://bugs.freedesktop.org/attachment.cgi?id=137579&action=edit photo of ht ekernel panic messages/ NMI Hello With all kernels 4.l5 when I start a shutdown with "shutdown -r now" from the console (ALT-CRL-F1) I receive a kernel panic with a NMI. System is a HP proliant ML350p with tumbleweed with default kernel. System updated always with "zypper dup" No message in logs found Video is a Nvidia Quadro 4100m running with nouveau driver and two screens last line on screen is nouveau:0000:0a:00.0 DRM: GPU Lockup _ switching to software fbcon After some time (10-15 seconds) the system starts all fans at maximum speed. I must then do a hard reset. I attach here a screenshot with the kernel Panic (jpg) Current kernel Linux hpprol2 4.15.3-1-default #1 SMP PREEMPT Tue Feb 13 07:58:49 UTC 2018 (8d4f579) x86_64 x86_64 x86_64 GNU/Linux Regards Philippe -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 98634] Fedora 32bits kernel 4.8.4-200.fc24.i686+PAE is not able to resume from hibernate
by bugzilla-daemon＠freedesktop.org 14 Oct '19

14 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=98634 Bug ID: 98634 Summary: Fedora 32bits kernel 4.8.4-200.fc24.i686+PAE is not able to resume from hibernate Product: DRI Version: XOrg git Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/other Assignee: dri-devel(a)lists.freedesktop.org Reporter: humberto.i.perez.rodriguez(a)intel.com Created attachment 127824 --> https://bugs.freedesktop.org/attachment.cgi?id=127824&action=edit dmesg.log Bug description ======================================= Fedora 32bits kernel 4.8.4-200.fc24.i686+PAE is not able to resume from hibernate, after send the platform to S4 / hibernate looks like that the platforms is not able to enter to S4 because the post code remains in "0004" and never shutdown completly how does it happen in Fedora 64bits Note : this bug does not appears in Fedora 64bit with kernel 4.5.5-300-fc24.x86_64 Steps to reproduce ======================================= 1. Install Fedora 24 32bits 2. Go to hibernate with either of the following commands : # rtcwake -s 60 -m disk # echo disk > /sys/power/state 3. if you try with the second command try to wake up the platform pushing any key / if you try with the first command wait 60 seconds Expected behavior ======================================= The platforms must resume from S4 / hibernate Actual result ======================================= After the step 3 the platform does not resume from S4 / hibernate Software configuration ============================================ Linux OS : Fedora 32Bit Kernel version : 4.8.4-200.fc24.i686+PAE Bios revision : 144.10 Bios release date : 06/27/2016 KSC revision : 1.15 Hardware information ============================================ Platform : BXT-P Motherboard model : BroxtonP Motherboard type : NOTEBOOK Hand Held Motherboard manufacturer : IntelCorp. CPU family : Other CPU information : 06/5c GPU Card : Intel Corporation Atom/Celeron/Pentium Processor N4200/N3350/E3900 Series Integrated Graphics Controller (rev 0a) (prog-if 00 [VGA controller]) Memory ram : 8 GB Maximum memory ram allowed : 16 GB CPU thread : 4 CPU core : 4 Attachments =========================================== dmesg.log, which containg the log when the platforms try to enter to S4 state Additional information =========================================== in order to send the platform to S3 (suspend) / S4 (hibernate) you have to enable it in the grub in the following way : 1. $ dmesg | grep -i "swap on" # to know where is your swap partition example : /dev/mapper/fedora-swap 2. add the following parameter in the file /etc/default/grub resume=/dev/mapper/fedora-swap add it at the end of the line : GRUB_CMDLINE_LINUX= 3. update the grub : grub2-mkconfig -o /boot/grub2/grub.cfg this a common issue in Fedora, for more detail information please read the following article : https://fedoraproject.org/wiki/Common_F24_bugs#Hibernation_doesn.27t_work_f… Please correct me if i am placing this issue in the wrong component, thanks i915_error_state = no error state collected cat /sys/class/drm/card0/error = no error state collected -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 102972] Flickering since 4.11
by bugzilla-daemon＠freedesktop.org 14 Oct '19

14 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=102972 Bug ID: 102972 Summary: Flickering since 4.11 Product: DRI Version: XOrg git Hardware: All OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/other Assignee: dri-devel(a)lists.freedesktop.org Reporter: lionel-fdo(a)lefolgoc.net Created attachment 134458 --> https://bugs.freedesktop.org/attachment.cgi?id=134458&action=edit bisect log (drm) Hi, (I've only Intel hardware available but since git bisect shows the culprit in drm and not drm/i915, I've filed it against DRM/other, feel free to reassign) Since 4.11, I've noticed major flickering on some displays I have (reproducible 100%). By flickering I mean the screen is mostly black and every few seconds I can see a flash with the screen content and it goes black again. It only occurs with the preferred mode, i.e. when I force a modeline to another mode in xorg.conf the flickering does not occur. I've tried all versions up to latest 4.14.0-rc2 and it is still reproducible, 4.10.x were fine. The display driver used (intel or modesetting) does not make a difference. I tried on all hardware I have here (NUC gen4 d5420, NUC5i5 and NUC6i5SYB) and the behavior is the same. I tried miniDP and HDMI, and it does not change anything. The captured logs below have been run on a NUC6i5SYB connected with miniDP, running CentOS 7.3, with the kernel 4.11.8 (from mainline, no ct7 or rhel patches). The git bisect was also run on this machine. Git bisect identified fcc8a22cc9053a8d1bbb94833ec103cd5961feef as first bad commit. With the log files below, 4.11.8-1 is "original" 4.11.8 kernel (bad), and 4.11.8-2 includes the commit reverted (good). >From the git bisect log and the fact it can be worked around with another modeline, I'm not even sure this is a regression in the kernel, as this might be that the screen is advertising something it cannot support properly... Thanks. -- You are receiving this mail because: You are the assignee for the bug.

1 11

[Bug 91481] [Patch?] DisplayPort MST (Multistream Transport) hotplug kernel memory fault
by bugzilla-daemon＠freedesktop.org 14 Oct '19

14 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=91481 Bug ID: 91481 Summary: [Patch?] DisplayPort MST (Multistream Transport) hotplug kernel memory fault Product: DRI Version: XOrg git Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/other Assignee: dri-devel(a)lists.freedesktop.org Reporter: adam_richter2004(a)yahoo.com Created attachment 117412 --> https://bugs.freedesktop.org/attachment.cgi?id=117412&action=edit Path to make drm_dp_send_link_address set link_address_sent before hotplug handler changes the pointer to it When I "hot plug" insert a DisplayPort multistream transport ("MST") hub into a computer that is running a Linux 4.2-rc4 kernel or any recent version, I get a kernel memory fault in drm_dp_add_port. In earlier kernels, I traced it to the line after drm_dp_add_port's call to drm_dp_send_link_address: drm_dp_send_link_address(mstb->mgr, port->mstb); port->mstb->link_address_sent = true; I believe that the problem is that drm_dp_send_link_address can call a hotplug handler, which can change port->mstb so that it cannot be dereferenced (I think it is set to NULL, but I have forgotten). Since drm_dp_send_link_address is a static function in this file, its address is never taken, and there are only two call sites, both of which set link_address_sent to true, the patch that I have attached changes drm_dp_send_link_address so that it sets that flag, reducing duplication of code, and also allowing drm_dp_send_link_address to skip setting the flag if sending the link address fails. An intentional behavior change introduced by this patch is that the mstb->link_address_sent is not set if sending the link address was aborted due to the memory allocation in drm_dp_send_link_address failing. Perhaps it should also not be set if the action receives a NAK reply, but I haven't studied the code and DisplayPort documentation enough to guess. Whoever examines this patch should feel free to revise it as they see fit. I should also warn that after I made this change in linux-4.2-rc4, the resulting kernel eventually got another kernel memory fault in i2c_transfer (called by drm_do_probe_ddc_edid), but I believe that that is a separate issue. I am happy to answer questions about this patch. If nobody sees any problems with it, I would ask that whoever takes this bug report submit the patch upstream. Thanks for considering this bug report and proposed patch. -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 105051] circular locking,
by bugzilla-daemon＠freedesktop.org 14 Oct '19

14 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=105051 Bug ID: 105051 Summary: circular locking, Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/other Assignee: dri-devel(a)lists.freedesktop.org Reporter: bugzilla(a)colorremedies.com 4.16.0-0.rc0.git9.1.fc28.x86_64 which is "linux-next" git f9f1e414128e [ 9.523799] switcheroo-cont/889 is trying to acquire lock: [ 9.523799] (console_lock){+.+.}, at: [<000000002c1cc7fb>] vga_switchto_stage2+0x93/0x130 [ 9.523806] but task is already holding lock: [ 9.523807] (vgasr_mutex){+.+.}, at: [<000000007e504e29>] vga_switcheroo_debugfs_write+0x6b/0x360 [ 9.523810] which lock already depends on the new lock. [ 9.523810] the existing dependency chain (in reverse order) is: [ 9.523810] -> #3 (vgasr_mutex){+.+.}: [ 9.523812] -> #2 (&helper->lock){+.+.}: [ 9.523814] -> #1 ((fb_notifier_list).rwsem){++++}: [ 9.523816] -> #0 (console_lock){+.+.}: [ 9.523818] other info that might help us debug this: [ 9.523818] Chain exists of: console_lock --> &helper->lock --> vgasr_mutex -- You are receiving this mail because: You are the assignee for the bug.

1 7

[Bug 110139] Driver throws exceptions when external display is connected over HDMI
by bugzilla-daemon＠freedesktop.org 14 Oct '19

14 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=110139 Bug ID: 110139 Summary: Driver throws exceptions when external display is connected over HDMI Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: General Assignee: dri-devel(a)lists.freedesktop.org Reporter: bastiborchers(a)gmx.net Created attachment 143690 --> https://bugs.freedesktop.org/attachment.cgi?id=143690&action=edit The complete output of dmesg Hello! Let me state right now that this is my first bug report and I am a little bit lost about what criteria I have to fulfill and whether I am reporting for the correct component. My system: I am using Arch Linux with the 5.0.1 Linux kernel. I have a Thinkpad P1 laptop with an Intel 8750H and an NVidia Quadro P1000. What happens: Before I turn on my laptop, I connected my external display via HDMI. Then I turn on my laptop and reach the bare tty (I am not using any Login Manager). While the tty is displayed, a lot of kernel messages are printed to the standard output about nouveau having some problems. As soon as I try to login (which starts my Window Manager, Sway), the system freezes and I have to hard reset my Laptop. Workaround: When I disconnect the HDMI cable before booting and connect it AFTER I logged into my system, then my external display works correctly. I dumped my whole dmesg output into the attached 'system.log' file, and I also retrieved the VBIOS information for my external display, I think. Let me know, if I can provide any further information and again, excuse any noob mistakes. -- You are receiving this mail because: You are the assignee for the bug.

1 4

[PATCH v7 0/9] drm: cec: convert DRM drivers to the new notifier API
by Dariusz Marcinkiewicz 14 Oct '19

14 Oct '19

This series updates DRM drivers to use new CEC notifier API. Changes since v6: Made CEC notifiers' registration and de-registration symmetric in tda998x and dw-hdmi drivers. Also, accidentally dropped one patch in v6 (change to drm_dp_cec), brought it back now. Changes since v5: Fixed a warning about a missing comment for a new member of drm_dp_aux_cec struct. Sending to a wider audience, including maintainers of respective drivers. Changes since v4: Addressing review comments. Changes since v3: Updated adapter flags in dw-hdmi-cec. Changes since v2: Include all DRM patches from "cec: improve notifier support, add connector info connector info" series. Changes since v1: Those patches delay creation of notifiers until respective connectors are constructed. It seems that those patches, for a couple of drivers, by adding the delay, introduce a race between notifiers' creation and the IRQs handling threads - at least I don't see anything obvious in there that would explicitly forbid such races to occur. v2 adds a write barrier to make sure IRQ threads see the notifier once it is created (replacing the WRITE_ONCE I put in v1). The best thing to do here, I believe, would be not to have any synchronization and make sure that an IRQ only gets enabled after the notifier is created. Dariusz Marcinkiewicz (9): drm_dp_cec: add connector info support. drm/i915/intel_hdmi: use cec_notifier_conn_(un)register dw-hdmi-cec: use cec_notifier_cec_adap_(un)register tda9950: use cec_notifier_cec_adap_(un)register drm: tda998x: use cec_notifier_conn_(un)register drm: sti: use cec_notifier_conn_(un)register drm: tegra: use cec_notifier_conn_(un)register drm: dw-hdmi: use cec_notifier_conn_(un)register drm: exynos: exynos_hdmi: use cec_notifier_conn_(un)register .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 13 +++--- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 46 +++++++++++++------ drivers/gpu/drm/drm_dp_cec.c | 25 ++++++---- drivers/gpu/drm/exynos/exynos_hdmi.c | 31 +++++++------ drivers/gpu/drm/i2c/tda9950.c | 12 ++--- drivers/gpu/drm/i2c/tda998x_drv.c | 36 ++++++++++----- drivers/gpu/drm/i915/display/intel_dp.c | 4 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 13 ++++-- drivers/gpu/drm/nouveau/nouveau_connector.c | 3 +- drivers/gpu/drm/sti/sti_hdmi.c | 19 +++++--- drivers/gpu/drm/tegra/output.c | 28 ++++++++--- include/drm/drm_dp_helper.h | 17 ++++--- 13 files changed, 155 insertions(+), 94 deletions(-) -- 2.23.0.rc1.153.gdeed80330f-goog

10 52

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2019