https://bugzilla.kernel.org/show_bug.cgi?id=58981
Summary: Bisected regression; boot failure with Radeon 9250 PCI
256MB + KMS
Product: Drivers
Version: 2.5
Kernel Version: 2.6.35,3.2.45,3.10-rc2
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Video(DRI - non Intel)
AssignedTo: drivers_video-dri(a)kernel-…
[View More]bugs.osdl.org
ReportedBy: jdietrch(a)fastmail.fm
Regression: Yes
I have a Radeon 9250 PCI 256MB video card in my machine. I discovered that this
machine would not boot with 3.2.45 when KMS was enabled by default in the
kernel config. Immediately after the grub menu, the screen would go black and
nothing more would happen. Or sometimes columns of character-sized "marks"
would appear on the screen. In either case, though, the machine would not boot.
So I went back to 2.6.33 and found that booting with KMS did work just fine
there.
So I used git bisect to find where the problem arose, and that pointed to this
commit which was merged for 2.6.35:
commit 6b8b1786a8c29ce6e32298b93ac8d4a18a2b11c4
Author: Jerome Glisse <jglisse(a)redhat.com>
Date: Wed Apr 7 10:21:31 2010 +0000
drm/radeon/kms: enable use of unmappable VRAM V2
I confirmed this result of git bisect by checking out 2.6.35 final and
reverting that one commit, and the resulting kernel booted fine with KMS
enabled by default.
I also tried 3.10-rc2 and that booted fine when I added radeon.modeset=0 to the
kernel commandline.
I will attach files with dmesg output and lspci. Please let me know if there is
anything else I can do. I'll be happy to test a proposed fix if that would be
helpful.
Thank you,
James Dietrich
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
[View Less]
https://bugzilla.kernel.org/show_bug.cgi?id=64721
Bug ID: 64721
Summary: Radeon HD6450 fails on all distro's out of box.
Product: Drivers
Version: 2.5
Kernel Version: Linux 3.2.04-amd64
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Video(DRI - non Intel)
Assignee: drivers_video-dri(a)kernel-bugs.osdl.org
…
[View More] Reporter: ichapman(a)videotron.ca
Regression: No
I think I'm at the right place to report video card frustrations.
Radeon HD450 fails to work out of the box with any Linux.
With Debian Wheezy I need to edit the grub line starting with linux and add
vga=791 to do anything. vga=771 fails
With Knoppix 7.0 I need vga=771 and that's okay, but vga=791 the left half of
screen is on right and right on left. The cursor moves to right falls off the
screen and re-appears on left side. Very strange.
With DebianMint I need vga=771 or 791 to get it to work.
On my Acer Aspire laptop with a Radeon HD6310 I do not need any of this vga=
stuff.
I am sure that this is not a driver problem. All the vga=xxx does is kick it
somewhere so that I loads the driver.
My Motherboard is M2V-Mx from Asus and once the /etc/default/grub is fixed with
GRUB_CMDLINE_LINUX="vga=791" or 771 it's okay. (sudo update-grub of course)
I recently junked my Nvidia 8500GT video because the driver for that became
sick, the worst feature was not being able to display the layout of the pcb
tool unless I disabled the driver and used cpu sw rendering on the video but
that's an other story. Ian.
--
You are receiving this mail because:
You are watching the assignee of the bug.
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=97055
Bug ID: 97055
Summary: Black screens on A10-8780P (Carrizo) + R7 M260/M265
(Topaz) Combo
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: critical
Priority: medium
Component: DRM/AMDgpu
Assignee: dri-devel(a)lists.freedesktop.org
Reporter: darktjm(…
[View More]a)gmail.com
Created attachment 125267
--> https://bugs.freedesktop.org/attachment.cgi?id=125267&action=edit
dmesg from my latest boot (with some wifi messages at end deleted for privacy)
I have an HP Pavilion 17-g133cl with A10 Carrizo+Topaz. I struggled for
hours/days to get this to actually display anything at all using the amdgpu
driver. In the mean time, efifb works perfectly every time (except of course
no 3d, no X resolution switching, no brightness control, and slow enough that
video playing is also impossible). Since it seemed like there were just issues
powering up the display controller correctly, I decided at first to add my
notes to https://bugzilla.kernel.org/show_bug.cgi?id=117591 but my symptoms
(and cures) are, indeed, different. After much blind playing with my system (I
have no way to ssh in, and the keyboard is flaky as well, so that was a lot of
fun), I made the following observations:
- kernel power management options appeared to have no effect
- sometimes (very rarely), it just starts working, regardless
- once it starts working for more than 1 minute, it stays working
- often, it starts partially working, by giving me a flickering display
- often, it starts working with a stable display, only to start flickering
again after a few seconds (very rarely even going completely black gain)
- my first way of fixing it is fairly reliable, but almost always requires at
least one blind reboot before it starts giving my a display: xrandr --output
eDP --crtc 1 (added to my .xinitrc)
- if, when it finally comes up, it is flickering, it can be cured by
toggling the crtc between 0 and 1 often enough until it remains stable for at
least a minute.
- if crtc 1 is enabled when X is killed, the machine goes blank and hangs
hard; switching consoles while X is up works, though (although the consoles
remain black).
- changing the crtc to 1 in X does nothing for the console; only X displays
anything. I have not tried to write a libdrm program to make the console
switch to crtc 1, nor have I managed to trace where the crtc list comes from,
or how to force it in the amdgpu driver itself.
- if, instead of playing with the crtc, I play with power management again,
I seem to be able to get it working by booting once with power management
enabled, then rebooting with it disabled, and then it works (video in console
as well as X, and no crtc switching necessary). However, that may just have
been how it decides to work today, and tomorrow it will no longer work.
I get identical behavior with kernels 4.6.2, 4.6.3, 4.6.4, 4.7-rc4 (which I
decided to try given the supposed major amdgpu overhaul), 4.4.15 (which I
decided to try given that the poster of the kernel.org bug was using Ubuntu's
4.4 kernel) (all on Gentoo; with the exception of 4.7-rc4, this is with
Gentoo's fbdecor patches, but I obviously have that disabled while working
through this problem).
Overall, this is very weird and frustrating. I've had power management issues
with previous Radeon laptops (all of them), but the gpu pm issue usually
manifested as hard locks while playing games with power management enabled, not
this crap. I have a feeling that anything that gets it to work only gets it to
work due to random chance, and it's just that I'm beating at it often enough
that I finally hit the jackpot at some point, and it keeps working correctly
until I power cycle for an extended period again. I also get the feeling that
I must be a major masochist to keep using ATI/AMD hardware, given that in 15+
years of using it I've never had an experience better than "meh, mostly works".
If I weren't dead broke, I'd have chucked this machine over a freeway overpass
and bought something else.
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]
This patch considers low power transmisson to two clock behaviors,
non-continuous and continuous clock mode.
These two clock behaviors can transmit data in high speed or low power.
So this patch series adds a new flag, MIPI_DSI_MODE_LPM so that each
host driver can setup its host controller properly.
Patch 1:
Add MIPI_DSI_MODE_LPM flag. If panel driver sets this flag, then msg->flags
will have MIPI_DSI_MSG_USE_LPM so that host driver can transmit data in low
power.
Patch 2:
Just exynos …
[View More]part for supporting non-continuous and continuous clock mode.
Inki Dae (2):
drm/mipi-dsi: consider low power transmission
drm/exynos: mipi-dsi: consider non-continuous clock mode
drivers/gpu/drm/drm_mipi_dsi.c | 6 ++++++
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 19 +++++++++++++++++++
include/drm/drm_mipi_dsi.h | 2 ++
3 files changed, 27 insertions(+)
--
1.7.9.5
[View Less]
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 …
[View More]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.
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=92977
Bug ID: 92977
Summary: Display artifacts when using MST
Product: DRI
Version: XOrg git
Hardware: Other
OS: 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 119730
--> https://bugs.freedesktop.…
[View More]org/attachment.cgi?id=119730&action=edit
image 1 - half of window uses different colors
I've been trying out the support for tiled MST monitors on Radeon drivers, and
seem to be encountering some visual anomalies that seem like they are likely to
be related to this component.
My setup is two UP2414Q monitors, which have native resolutions of 3840x2160.
Over DisplayPort 1.2, they are capable of running as two 1920x2160@60 displays
each. I have a nvidia card that is capable of driving them in this mode, so I
am reasonably sure that the hardware isn't the problem (unless it is the Radeon
card, but that seems unlikely).
First, there seems to be a color anomaly with the primary display. The right
half of the display has different colors from the left (see first image). I
noticed that this may be due to the left half displaying a different color
depth than the right. The second image shows the gnome overlay, and while the
shadows are smooth on the right, there is banding on the left. My second
monitor seems to have both sides in this reduced color mode, and enough
fiddling with settings after a boot causes both halves of the primary monitor
to be configured that way as well, but needless to say, the reduced color depth
(if that's what it is) is undesirable.
Second, the secondary monitor has some visual artifacts to the left of center
(a vertical band about an inch wide) as well as to the far right (a vertical
band around 1/4 inch wide). The third image should give some idea what it looks
like. A better photo might show that things in that region look somewhat
interlaced, and are repeated horizontally.
I apologize for the poor quality of the images, but screenshots don't capture
these artifacts, so I had to use my phone.
I'm running with packages from Fedora 23, so xorg-server 1.18.0, xf86-video-ati
7.6.0-0.4.20150729git5510cd6, kernel 4.2.5-300. If you'd like any other
information, let me know.
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]
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 (…
[View More]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.
[View Less]
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]