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)
--> (…
[View More]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.
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=97157
Bug ID: 97157
Summary: MST displays fail to wake
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: dan.doel(a)gmail.com
Created attachment 125450
--> https://bugs.…
[View More]freedesktop.org/attachment.cgi?id=125450&action=edit
dmesg output
Since moving to kernel 4.6, I've been having regular problems with my MST
monitors failing to wake after being put to sleep. This only seems to occur
after the machine has been on for a sufficient amount of time, but I usually
experience it within a day of booting, and typically after the displays have
been powered off for an extended period of time.
There are two MST monitors, but typically only one fails to wake. Also, it is
more often that the secondary display is the one that fails. However, I have
had the primary display fail to come back (while the secondary one succeeds),
and I have had both fail to come back as well.
Sometimes, only a complete power off is able to make the monitors wake up; a
reboot is not always sufficient.
The dmesg displays some errors, and I've poked around a bit. It seems likely
that this is related to commit f3d58dccdbf9f8c0a229d555d4b295d52e743039, which
was first included in 4.6. This commit basically causes dpms to work at all
with MST monitors; before it was a no-op that didn't actually put the monitors
into power saving. That doesn't help narrow the problem down much, though,
since a significant portion of the mst dpms code probably wasn't being
exercised before that.
Also, it seems notable that the error message (which seems more like a debug
message) in the STANDBY/SUSPEND/OFF case keeps reporting higher numbers, as
though it keeps going through the ON case, which increments the variable, but
not making it through the portion of the OFF case that decrements the variable.
I'll attach dmesg journal output that might be relevant. I believe the
error/debug messages timestamped 'Jul 31 11:03:49' correspond to the first time
one of the displays failed to wake up. I tried various ways of toggling the
dpms off and on after that, so those are the subsequent error messages in the
log.
As far as specs go, I have:
Radeon HD7870 (Pitcairn)
Kernel 4.6.4 (4.6.3 also affected)
2 UP2414Q mst displays
xorg-server 1.18.4
Modesetting driver
Let me know if there's any more information I can try to provide.
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=94153
Bug ID: 94153
Summary: Unresponsive system on boot with radeon + HD 3870
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: blocker
Priority: medium
Component: DRM/Radeon
Assignee: dri-devel(a)lists.freedesktop.org
Reporter: g47qk(a)ukr.net
Created attachment 121755
…
[View More]--> https://bugs.freedesktop.org/attachment.cgi?id=121755&action=edit
dmesg.log saved via the serial port
I'm using a HD 3870 with Debian 9 Stretch x64 (Testing). When booting to a
command line, when drivers are loaded, the screen goes into power saving mode,
and the system becomes unresponsive.
Booting with `nomodeset' works OK. If I run "#modprobe radeon modeset=1", the
screen goes power saving mode, the system stops responding and the caps lock
key no longer works (kernel panic?).
I've also tested with a Fedora 23 Workstation Live-CD (64-bit), Ubuntu 15.10
Desktop (64-bit) Live-CD, SystemRescueCd-x86-4.7.0 with the same results
(unresponsive on driver load).
I've tested a ATI X1600 Pro in the same system, and everything works fine.
#lspci -nnn | grep VGA
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] RV670 [Radeon HD 3870] [1002:9501]
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]
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 …
[View More]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.
[View Less]
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
…
[View More] 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.
[View Less]
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/…
[View More]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.
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=100800
Bug ID: 100800
Summary: With KMS:No link with displayport and A6-3600 APU from
4.4.x to 4.11.0.rc8, unless nomodeset kernel boot
parameter
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: DRM/Radeon
Assignee: dri-devel(a)…
[View More]lists.freedesktop.org
Reporter: abittner(a)opensuse.org
With KMS:No link with displayport and A6-3600 APU from 4.4.x to 4.11.0.rc8,
unless nomodeset kernel boot parameter
Please see my original distribution bugreport at
<https://bugzilla.opensuse.org/show_bug.cgi?id=1035240>
Tested with OpenSuSE Leap 42.2 (all x64) kernels 4.4.x up to 4.11.0.rc8 kernels
Hardware:
Motherboard: F1A75-V PRO by Asus, with AMD cpu/gpu/apu all-in-one: AMD A6-3600
APU with Radeon(tm) HD Graphics
hdmi port on motherboard and on the same monitor with hdmi cable works and
produces link, same motherboard with displayport cable and ports and same
monitor at its displayport port gives no link, unless one uses the "nomodeset"
kernel boot parameter.
Thank you.
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=100712
Bug ID: 100712
Summary: ring 0 stalled after bytes_moved_threshold reached -
Cap Verde - HD 7770
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: DRM/Radeon
Assignee: dri-devel(a)lists.freedesktop.org
Reporter: julien.isorce(a)gmail.…
[View More]com
Kernel 4.9 from
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-4.9 and latest
mesa. (same result with drm-next-4.12 branch)
Same result with kernel 4.8 and mesa 12.0.6.
In kernel radeon_object.c::radeon_bo_list_validate, once "bytes_moved >
bytes_moved_threshold" is reached (this is the case for 850 bo in the same
list_for_each_entry loop), I can see that radeon_ib_schedule emits a fence that
it takes more than the radeon.lockup_timeout to be signaled.
In radeon_fence_activity, I checked that the "last_emitted" is the seq number
for this last emited fence. And last_seq is equal to last_emitted-1.
Then the next call to ttm_wait_bo blocks (15 * HZ > radeon.lockup_timeout)
until gpu lockup which leads to a gpu reset.
Also it seems the fence is signaled by swapper after more than 10 seconds but
it is too late. I requires to reduce the "15" param above to 4 to see that.
Is it normal that radeon_bo_list_validate still tries to move the bo if
bytes_moved_threshold is reached ? Indeed ttm_bo_validate is always called (it
blits from vram to vram).
Is it also normal that ttm_bo_validate is called with evict flag as true once
bytes_moved_threshold is reached ?
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=100675
Bug ID: 100675
Summary: No signal on DisplayPort [drm:radeon_dp_link_train
[radeon]] *ERROR* displayport link status failed
Product: DRI
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: DRM/Radeon
Assignee: dri-devel(a)lists.freedesktop.org
…
[View More]Reporter: oleg.hoefling(a)gmail.com
Created attachment 130835
--> https://bugs.freedesktop.org/attachment.cgi?id=130835&action=edit
dmesg log
First of all, this is the first bug reported by me, so I apologize in advance
if I assigned it to a wrong category. I have a monitor, a DisplayPort cable and
two notebooks. When the monitor is connected to the first notebook (Lenovo
T440), everything works fine, so the cable seems is working fine. Now, when the
monitor is connected to the second notebook, it shows "no signal is detected"
and switches into sleep mode. Here is what dmesg outputs (I will attach the
complete dmesg log):
[ 12.064503] [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link
status failed
[ 12.064517] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery
failed
Of course, after logging into the X session, the monitor remains black,
although Xorg does not report any errors in log:
$ grep -n EE /var/log/Xorg.0.log
16: (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
System:
Linux msi_gx70 4.10.9-gentoo #2 SMP Thu Apr 13 21:30:04 CEST 2017 x86_64 AMD
A10-5750M APU with Radeon(tm) HD Graphics AuthenticAMD GNU/Linux
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=100616
Bug ID: 100616
Summary: With Radeon HD 8550M system freezes when running 3D
application
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: major
Priority: medium
Component: DRM/Radeon
Assignee: dri-devel(a)lists.freedesktop.org
Reporter: erham65t(a)…
[View More]yahoo.com
Created attachment 130753
--> https://bugs.freedesktop.org/attachment.cgi?id=130753&action=edit
dmesg output
My laptop has hybrid graphics.
Output of "lspci | grep AMD":
"0a:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Sun LE
[Radeon HD 8550M / R5 M230] (rev ff)"
I use an application called "Visual Molecular Dynamics", which opens an OpenGL
window and renders 3D images. There is no problem when using the integrated
GPU. But when I run the application using DRI_PRIME=1, the system freezes when
the OpenGL window is being opened. I need to use the dedicated GPU, because the
integrated GPU isn't powerful enough for my work.
OS: Ubuntu 16.04 64bit, with last updates
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]