https://bugzilla.kernel.org/show_bug.cgi?id=47481
Summary: Random blank screen: radeon_cs_ib_chunk Failed to schedule IB on AMD PALM Product: Drivers Version: 2.5 Kernel Version: 3.5.3, 3.6.0-rc5 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri@kernel-bugs.osdl.org ReportedBy: anisse@astier.eu Regression: No
Created an attachment (id=80131) --> (https://bugzilla.kernel.org/attachment.cgi?id=80131) Dmesg of the problem
Hi,
Randomly I might get a bug on an AMD E1-1200 : screen won't turn on and when X is supposed to start I get a lot of these: [ 307.718332] radeon 0000:00:01.0: couldn't schedule ib [ 307.718348] [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! [ 307.719063] radeon 0000:00:01.0: couldn't schedule ib [ 307.719075] [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! [ 307.734461] radeon 0000:00:01.0: couldn't schedule ib [ 307.734476] [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! [ 307.735489] radeon 0000:00:01.0: couldn't schedule ib [ 307.735502] [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB !
They stop once X is stopped.
Full dmesg in attachment.
Extract of my xorg.conf: Section "Device" Identifier "Card0 Driver "radeon" Option "DRI" EndSection
https://bugzilla.kernel.org/show_bug.cgi?id=47481
--- Comment #1 from Anisse Astier anisse@astier.eu 2012-09-13 17:18:45 --- Correction: screen is blank, but backlight is on.
https://bugzilla.kernel.org/show_bug.cgi?id=47481
Alex Deucher alexdeucher@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alexdeucher@gmail.com
--- Comment #2 from Alex Deucher alexdeucher@gmail.com 2012-09-13 17:19:43 --- Is this a regression? If so what components did you change (kernel, mesa 3D driver, radeon xorg driver, etc.).
https://bugzilla.kernel.org/show_bug.cgi?id=47481
--- Comment #3 from Anisse Astier anisse@astier.eu 2012-09-13 17:27:23 --- I'm not sure. Since it's random I need to do a lot of tests to reproduce it. I'll try to test with 3.2.
Sometimes, screen might turn on, but I get vertical black and white stripes. (I have a photo if you need one).
My current stack is: - kernel 3.5.3, but it also crashes/bugs with kernel 3.6.0-rc5 - mesa 8.0.4 - DDX 6.14.4 - xserver 1.7.7
Not sure it's relevant since the problem starts before X when modesetting should kick in (screen is blank).
https://bugzilla.kernel.org/show_bug.cgi?id=47481
--- Comment #4 from Anisse Astier anisse@astier.eu 2012-09-14 10:16:22 --- I think it is indeed a regression. After many power cycles, I wasn't able to reproduce it with 3.2.16.
This is going to take forever to bisect…
https://bugzilla.kernel.org/show_bug.cgi?id=47481
Anisse Astier anisse@astier.eu changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression|No |Yes
https://bugzilla.kernel.org/show_bug.cgi?id=47481
--- Comment #5 from Anisse Astier anisse@astier.eu 2012-09-17 17:41:33 --- I did a first round of bisect: 375849ce878f1a2dfac12ea2a62b361ab6b7f9a5 is the first bad commit commit 375849ce878f1a2dfac12ea2a62b361ab6b7f9a5 Author: Jerome Glisse jglisse@redhat.com Date: Fri Jul 27 16:32:24 2012 -0400
drm/radeon: do not reenable crtc after moving vram start address
commit 81ee8fb6b52ec69eeed37fe7943446af1dccecc5 upstream.
It seems we can not update the crtc scanout address. After disabling crtc, update to base address do not take effect after crtc being reenable leading to at least frame being scanout from the old crtc base address. Disabling crtc display request lead to same behavior.
So after changing the vram address if we don't keep crtc disabled we will have the GPU trying to read some random system memory address with some iommu this will broke the crtc engine and will lead to broken display and iommu error message.
So to avoid this, disable crtc. For flicker less boot we will need to avoid moving the vram start address.
This patch should also fix :
https://bugs.freedesktop.org/show_bug.cgi?id=42373
Problem: I'm not sure this is in fact the culprit, and that this commit didn't just uncover another bug. During the bisect between v3.5 and v3.5.3 I had another problem: machine would some time block at boot with a black screen (no backlight); I ignored it because it didn't have the same symptom (boot ok, blank screen, backlight on, error on X start).
That's why I'm not sure if the bug isn't more ancient (between v3.2 and v3.5).
https://bugzilla.kernel.org/show_bug.cgi?id=47481
--- Comment #6 from Alex Deucher alexdeucher@gmail.com 2012-09-18 14:41:46 --- This bug sounds kind of like the bugs that 375849ce878f1a2dfac12ea2a62b361ab6b7f9a5 fixes. Can you see if this is fixed in my drm-next-3.7-wip branch: http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.7-wip I have a more complete set of patches to properly disable MC clients when changing the MC.
https://bugzilla.kernel.org/show_bug.cgi?id=47481
--- Comment #7 from Anisse Astier anisse@astier.eu 2012-09-18 16:46:05 --- After about 180 reboots, I can confirm that this bug isn't present anymore on drm-next-3.7-wip. But I wasn't able to find commit 375849ce878f1a2dfac12ea2a62b361ab6b7f9a5 . Which commit do you think contains the fix ?
I still have a seemlingly unrelated "screen off/lockup on reboot" problem (that shouldn't be a regression). But this is a story for another bug report.
https://bugzilla.kernel.org/show_bug.cgi?id=47481
--- Comment #8 from Alex Deucher alexdeucher@gmail.com 2012-09-18 17:00:44 --- The commit is: drm/radeon: properly handle mc_stop/mc_resume on evergreen+ (v2)
As of right now, it's here: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3.7-wip&id=2... but I rebase that branch regularly so it may change.
https://bugzilla.kernel.org/show_bug.cgi?id=47481
Anisse Astier anisse@astier.eu changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |CODE_FIX
--- Comment #9 from Anisse Astier anisse@astier.eu 2012-10-09 07:53:11 --- I was able to reproduce this bug on an AMD E2-1800 with kernel 3.6. I can confirm that backporting those two patches fixes the problem:
4a15903 drm/radeon/dce4+: don't use radeon_crtc for vblank callback 62444b7 drm/radeon: properly handle mc_stop/mc_resume on evergreen+ (v2)
It would be great if they could be imported to stable, if they are not demmed too invasive.
https://bugzilla.kernel.org/show_bug.cgi?id=47481
Andre andros@all-ein.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andros@all-ein.net
--- Comment #10 from Andre andros@all-ein.net 2012-11-25 19:03:33 --- I can confirm this bug on my AMD A8-3550-m Kernel 3.5.7 and 3.6.6 -> radeon.modeset=1
The trouble began about tree days ago, as i updated my Gentoo system (stable branch) and the following updates where installed:
xorg-server 1.12.4 => 1.13.0-r1 mesa 8.0.4-r1 => 9.0 xf86-video-ati 6.14.6-r1 => 7.0.0
After that i had strange artifacts in X and random crashes of the X-server. Where the mouse is movable but the windows are frozen and the screen turns black after a a short time.
I have test-installed 3 other linux distributions, all came out with the same bug, after upgrading the installations to the latest stable releases.
Sadly only after tree days of experimenting, i came to the conclusion that this error only occurs when the VGA output is active. With the LVDA or HDMI output i have no problems so far.
It's really sad to see, that this bug is two months old and now shows up in major Linux Distributions, in the >>stable-branches<<.
https://bugzilla.kernel.org/show_bug.cgi?id=47481
--- Comment #11 from Anisse Astier anisse@astier.eu 2012-11-25 22:23:45 --- Indeed. Bug is fixed in 3.7, but I still have to backport the two commits I cited on kernel <= 3.6. These should be proposed to stable (I thought they were).
https://bugzilla.kernel.org/show_bug.cgi?id=47481
--- Comment #12 from Alex Deucher alexdeucher@gmail.com 2012-11-26 03:01:56 --- They have been back-ported to certain stable kernels. E.g., https://patchwork.kernel.org/patch/1590951/ I'll see if I can get them applied to 3.6 as well if they haven't already been.
https://bugzilla.kernel.org/show_bug.cgi?id=47481
--- Comment #13 from Andre andros@all-ein.net 2012-11-27 20:17:53 --- I have to correct myself. The bug hits me again, this time only the HDMI output was active. Today after 4 hours the screen was blinking black and freezes except the mouse was movable.
I'm runing currently Linux 3.6.0-sabayon x11-drivers/xf86-video-ati-6.14.6-r1 media-libs/mesa-9_pre20120831-r1 x11-base/xorg-server-1.12.4
At the time the bug ocurs runing software: KDE-Desktop with effects on Chrome, Firefox, Thundebrird and VMWare Workstation.
now testing with Desktop effects off.
/var/log/messages -> http://pastebin.com/qQkX8qAQ /var/log/Xorg.0.log -> http://pastebin.com/v28mpB3i dmesg -> http://pastebin.com/U0Dzr7Qf
https://bugzilla.kernel.org/show_bug.cgi?id=47481
--- Comment #14 from Andre andros@all-ein.net 2012-12-16 23:22:54 --- I have tried the new kernel 3.7 and have the same behavior as described in the initial bug report.
/var/log/messages http://pastebin.com/a4EN1kmL
I will recompile the kernel with debugging enabled to maybe get a more detailed kernel.log.
https://bugzilla.kernel.org/show_bug.cgi?id=47481
--- Comment #15 from Alex Deucher alexdeucher@gmail.com 2012-12-17 00:34:33 --- Does this patch fix the issue? http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=bd25f07...
https://bugzilla.kernel.org/show_bug.cgi?id=47481
--- Comment #16 from Andre andros@all-ein.net 2012-12-17 16:11:28 --- Before i could crash X almost instantaneously by switching the kde (openGL) screensaver back and forth.
Now the system runs for almost two hours without any problems so far.
https://bugzilla.kernel.org/show_bug.cgi?id=47481
--- Comment #17 from Andre andros@all-ein.net 2012-12-18 22:23:33 --- Okay, after more than 30 hours uptime, i think this patch fixed it. :-)
dri-devel@lists.freedesktop.org