dri-devel May 2015

dri-devel@lists.freedesktop.org

191 participants
1132 discussions

[Bug 80684] New: I2C-over-AUX drops single bytes
by bugzilla-daemon＠freedesktop.org 20 Nov '19

20 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=80684 Priority: medium Bug ID: 80684 Assignee: dri-devel(a)lists.freedesktop.org Summary: I2C-over-AUX drops single bytes Severity: normal Classification: Unclassified OS: All Reporter: stefan.bruens(a)rwth-aachen.de Hardware: Other Status: NEW Version: DRI CVS Component: DRM/Radeon Product: DRI I get frequent errors for the EDID checksum, obviously single bytes are dropped from the EDID. Good EDID: Raw EDID: 02 03 1d f1 50 90 05 04 03 02 07 16 01 06 11 12 15 13 14 1f 20 23 09 7f 07 83 01 00 00 02 3a 80 18 71 38 2d 40 58 2c 25 00 55 50 21 00 00 1e 01 1d 80 18 71 1c 16 20 58 2c 25 00 55 50 21 00 00 <-- 9e 01 1d 00 72 51 d0 1e 20 6e 28 55 00 55 50 21 00 00 1e 8c 0a d0 8a 20 e0 2d 10 10 3e 96 00 55 50 21 00 00 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5d Bad EDID example: Raw EDID: 02 03 1d f1 50 90 05 04 03 02 07 16 01 06 11 12 15 13 14 1f 20 23 09 7f 07 83 01 00 00 02 3a 80 18 71 38 2d 40 58 2c 25 00 55 50 21 00 00 1e 01 1d 80 18 1c 16 20 58 2c 25 00 55 50 21 00 00 9e <-- 0x71 is missing 01 1d 00 72 51 d0 1e 20 6e 28 55 00 55 50 21 00 00 1e 8c 0a d0 8a 20 e0 2d 10 10 3e 96 00 55 50 21 00 00 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5d 00 The position of the dropped byte changes, sometimes the EDID is complete, sometimes several bytes are dropped. The bad EDIDs are *often* accompanied with [drm:radeon_process_aux_ch] dp_aux_ch flags not zero messages. Most probably the common i2c-over-aux code drops the byte, as it starts the transfer again in case of -EBUSY. If I change radeon_process_aux_ch to return -EIO in case of (ReplyStatus == 2), I no longer have any bad checksums. Hardware is Radeon 7750 + Dell U2713HM, connected via DP. Same monitor with Intel Haswell and different cable works without any errors. Kernel is 3.15.1, i.e. without the i2c bus mutex, dont know if this fixes the problems as well. -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 32556] New: screen flickers all the time with desktop image appearing only briefly
by bugzilla-daemon＠freedesktop.org 20 Nov '19

20 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=32556 Summary: screen flickers all the time with desktop image appearing only briefly Product: DRI Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: critical Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: 3ntr0p13(a)gmail.com Created an attachment (id=41344) --> (https://bugs.freedesktop.org/attachment.cgi?id=41344) dmesg Machine is the same as in bug report 28331 although with different software components: Acer Aspire L5100 with an AMD Athlon 64 X2 Dual Core Processor 4000+, this time running a 64 bits debian squeeze. The machine is a small factor desktop machine designed around laptop components, so the graphic card is an integrated radeon x1200. When running a linux vanilla kernel 2.6.37-rc6, the screen flickers all the time making the machine unusable, while with debian kernel 2.6.32-5 such "flick to black" event occur from time to time, making it annoying but usable. While booting with radeon.modeset=0 the problem doesn't exhibits itself The following packages version from debian squeeze are installed: xserver-xorg 1:7.5+8 xserver-xorg-core 2:1.7.7-10 xserver-xorg-video-radeon 1:6.13.1-2+squeeze1 Please find attached Xorg.0.log, dmesg, register dumps for ums and kms for that machine (when booted on 2.6.37-rc6). Regards, Gildas -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 38

[Bug 32422] New: Large images displayed in Firefox appear corrupted
by bugzilla-daemon＠freedesktop.org 20 Nov '19

20 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=32422 Summary: Large images displayed in Firefox appear corrupted Product: DRI Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: da_fox(a)mad.scientist.com Created an attachment (id=41150) --> (https://bugs.freedesktop.org/attachment.cgi?id=41150) Picture describing a thousand words. "A picture says more than a thousand words" (aka see attachment) This is what happens when I try to view the XKCD "Online Communities 2" map (http://xkcd.com/802_large/) or other large images in firefox. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 21

[Bug 89971] HDMI out *not* working with radeon (mobile 8550g)
by bugzilla-daemon＠freedesktop.org 20 Nov '19

20 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=89971 Bug ID: 89971 Summary: HDMI out *not* working with radeon (mobile 8550g) Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: adrianovidiugabor(a)gmail.com Created attachment 114999 --> https://bugs.freedesktop.org/attachment.cgi?id=114999&action=edit screen's content Hi all. If I'm connecting my laptop's HDMI out to my TV I get a black screen with garbage on top (see attached pic). This is with mirror mode on. If making the second screen primary, the pc blocks and I have to restart it. It won't unblock even if I disconnect the cable. If switching to one of the virtual consoles, everything works correctly as it should, so the problem seems to be related somehow to the display server. The Tv is recognized correctly by xrandr. Specs: Asus laptop, with AMD A8-5550M, Radeon 8550G(Aruba)/8670M(Hainan), OS ArchLinux(x64) Xorg-xerver 1.17, kernel 3.19.3, Mesa-git, xf86-ati-git, llvm-svn. This doesn't seem to be a regression (experienced it with older versions of the kernel and userspace components) and it's reproducible on another machine. HDMI out works on Windows and ChromeOS. Didn't try Catalyst on Linux. -- You are receiving this mail because: You are the assignee for the bug.

1 15

[Bug 80531] New: 3.16-rc2 hdmi output resolution out of range Cape Verde PRO [Radeon HD 7750]
by bugzilla-daemon＠freedesktop.org 20 Nov '19

20 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=80531 Priority: medium Bug ID: 80531 Assignee: dri-devel(a)lists.freedesktop.org Summary: 3.16-rc2 hdmi output resolution out of range Cape Verde PRO [Radeon HD 7750] Severity: normal Classification: Unclassified OS: Linux (All) Reporter: fredrik(a)obra.se Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 101759 --> https://bugs.freedesktop.org/attachment.cgi?id=101759&action=edit dmesg with drm.debug=1 With 3.16-rc2 my tripple screen setup breaks. DisplayPort-0 connected 1920x1200 <- ok HDMI-0 connected 1920x1080 <- (tv) resolution out of range DVI-0 connected 1680x1050 <- ok All screens work during bootup before X starts. ddx driver 7.3.0. -- You are receiving this mail because: You are the assignee for the bug.

1 14

[Bug 75992] New: Display freezes & corruption with an r7 260x on 3.14-rc6
by bugzilla-daemon＠freedesktop.org 20 Nov '19

20 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=75992 Priority: medium Bug ID: 75992 Assignee: dri-devel(a)lists.freedesktop.org Summary: Display freezes & corruption with an r7 260x on 3.14-rc6 Severity: major Classification: Unclassified OS: Linux (All) Reporter: edt(a)aei.ca Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI Created attachment 95520 --> https://bugs.freedesktop.org/attachment.cgi?id=95520&action=edit log of boot I recently added a R7 260X to my system. While the card works with 3.13 its supposed work much better with 14-rc. This is not the case. My system is unstable without radeon.dpm=0 which was the default in .13. linux 3.14-rc6 (with an up to date arch, stable X and mesa-git (10.2) mesa 10.1 and 10.0 also show very similar problems. When X started I did notice some corruption. There are sets of two rectangles about of a height of 2 or 3 mm, width of 25m or so with a second about a cm below. The often occurs in chomium especially when scrolling. Runing the unigine-sanctuary or unigine-tropics demo/benchmark programs also produce the above problems and eventually stall. -- You are receiving this mail because: You are the assignee for the bug.

1 61

[Bug 90340] RADEON "PITCAIRN" displayport output breaks when monitor turned off and on
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=90340 Bug ID: 90340 Summary: RADEON "PITCAIRN" displayport output breaks when monitor turned off and on Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: steve(a)einval.com As initially reporte in Debian at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783705 I'm running Debian Jessie (3.16.x kernel) on a machine with a Pitcairn-based video adapter and an NEC Multisync EA274WMi 27" monitor, connected via DisplayPort. I've also tried upgrading to the 4.0 kernel and I see exactly the same symptoms. If I turn the monitor off and then on again (as I was doing overnight), I get no display at all. I've wiggled the mouse, hit numlock on the keybard (the numlock led illuminates fine), etc., but no display. I've seen this kind of thing happen in the past on some machines, so I switch to VT1 and back to see if that helps. Still no display at all, either on console or under X. I log in remotely and I can see that the Xorg.0.log file has been updated with mode lines for the monitor, suggesting things have just woken up fine. But still no display. Here's the really weird thing: at this point, the monitor has basically locked up. It won't respond to the power/input/menu butttons at all, and is still showing the blue LED that says "I have signal" rather than switching to the amber "no signal" warning. Therefore, I can only assume there's a problem here with some weird invalid DP signal being produced. I've carried on playing with this. If I log in from another machine and run xrandr, I can see the display details of the monitor just fine. If I use xrandr to turn the display off and then on again: xrandr --output DisplayPort-0 --off xrandr --output DisplayPort-0 2560x1440 then things start working again. -- You are receiving this mail because: You are the assignee for the bug.

1 7

[Bug 90320] Lenovo ThinkPad E455 (Kaveri A10-7300): Blank built-in screen with radeon kms driver
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=90320 Bug ID: 90320 Summary: Lenovo ThinkPad E455 (Kaveri A10-7300): Blank built-in screen with radeon kms driver Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: blocker Priority: highest Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: sibradzic(a)gmail.com Created attachment 115550 --> https://bugs.freedesktop.org/attachment.cgi?id=115550&action=edit dmesg 4.1 rc1 As soon as the radeon kms switches in from efifb, the screen goes blank for the moment (no backlight), and then the backlight switches in, but the screen remains black. External HDMI output works just fine. No X is involved, I can't even see the kms console @ eDP. I can even control the backlight on the eDP display, but all i get is the various shades of black. Fglrx works fine, although it flickers wildly before the picture gets stable. I've tried numerous things, like forcing EDID that was grabbed from fglrx, disabling audio, applying all the DP training / backlight disabling patches as in https://bugs.freedesktop.org/show_bug.cgi?id=73530, all to no avail. Currently on linux 4.1rc1, tried 3.13, 3.16 & 3.19 as well, same issue. Please help! I bought this laptop cause I prefer AMD, and was expecting Lenovo to work great with Linux, but so far its broken. Ready to try some patches... -- You are receiving this mail because: You are the assignee for the bug.

1 23

[Bug 90291] X freeze/lockup out of nowhere
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=90291 Bug ID: 90291 Summary: X freeze/lockup out of nowhere Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: ancoron(a)chaoslayer.de Created attachment 115519 --> https://bugs.freedesktop.org/attachment.cgi?id=115519&action=edit Xorg.0.log of the crashed session I experienced a lockup/freeze without any specific reason. Operating system: Kubuntu 14.10 Linux Kernel: 3.19.0 libglamor version: 0.6.0+git20140801.347ef4f0-0ubuntu0sarvatt libdrm-radeon version: 2.4.60+git20150416.0d78b37b-0ubuntu0ricotz2~utopic xserver/radeon version: 7.4.99+git20140806.fbf575cb-0ubuntu0sarvatt3 MESA version: 10.6.0~git20150423.1 At the time of the hang I had started some rsync copying quite some data between two remote NFS mounts on different servers. When X freeze'd, the display went black and monitors turned into standby. Changing to another terminal was not possible, although keys like NumLock still reacted. In addition, all other processes - even foreground processes inside the X sessions' terminal windows - continued to run (like the rsync). The actual backtrace of the X freeze (debugging symbols where not installed up to now, sorry): (EE) 0: /usr/bin/X (xorg_backtrace+0x56) [0x7ff7b4c1c986] (EE) 1: /usr/bin/X (0x7ff7b4a66000+0x1bab69) [0x7ff7b4c20b69] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (0x7ff7b2798000+0x36eb0) [0x7ff7b27ceeb0] (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (0x7ff7b2798000+0x98168) [0x7ff7b2830168] (EE) 4: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (0x7ff7ac742000+0x16e7ce) [0x7ff7ac8b07ce] (EE) 5: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (0x7ff7ac742000+0x16ebd2) [0x7ff7ac8b0bd2] (EE) 6: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (0x7ff7ac742000+0x16f51a) [0x7ff7ac8b151a] (EE) 7: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (0x7ff7ac742000+0x1c604f) [0x7ff7ac90804f] (EE) 8: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (0x7ff7ac742000+0x1604fa) [0x7ff7ac8a24fa] (EE) 9: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (0x7ff7ac742000+0x16076a) [0x7ff7ac8a276a] (EE) 10: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (0x7ff7ac742000+0x160a78) [0x7ff7ac8a2a78] (EE) 11: /usr/lib/xorg/modules/libglamoregl.so (0x7ff7ade2a000+0x223e4) [0x7ff7ade4c3e4] (EE) 12: /usr/lib/xorg/modules/libglamoregl.so (0x7ff7ade2a000+0x225d2) [0x7ff7ade4c5d2] (EE) 13: /usr/lib/xorg/modules/libglamoregl.so (0x7ff7ade2a000+0x13b31) [0x7ff7ade3db31] (EE) 14: /usr/lib/xorg/modules/libglamoregl.so (0x7ff7ade2a000+0x13f0a) [0x7ff7ade3df0a] (EE) 15: /usr/bin/X (0x7ff7b4a66000+0x140103) [0x7ff7b4ba6103] (EE) 16: /usr/bin/X (0x7ff7b4a66000+0x53cd0) [0x7ff7b4ab9cd0] (EE) 17: /usr/bin/X (0x7ff7b4a66000+0x57077) [0x7ff7b4abd077] (EE) 18: /usr/bin/X (0x7ff7b4a66000+0x5b286) [0x7ff7b4ac1286] (EE) 19: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf5) [0x7ff7b27b9ec5] (EE) 20: /usr/bin/X (0x7ff7b4a66000+0x456ae) [0x7ff7b4aab6ae] (EE) (EE) Bus error at address 0x7ff7b4914000 (EE) Fatal server error: (EE) Caught signal 7 (Bus error). Server aborting -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 90263] GPU card fans run full speed at all times
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=90263 Bug ID: 90263 Summary: GPU card fans run full speed at all times Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: todd(a)todddailey.ca Arch w/ Linux 4. AMD "6770" "BARTS" GPU. GPU fans run at full speed at all times. Lots of promises on the forums that the fix would "just work" in Linux 4. It did not. Not an issue when dual-booted to Windows 7. Fans run properly. -- You are receiving this mail because: You are the assignee for the bug.

1 23

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2015