You are not logged in.
Hi!
I own a board: 880GMH/U3S3 with radeon chipset HD 4250.
I update very frequently to get current state of archlinux and to minimize migration efforts.
Last time I updated my system and encountered screen corruptions after the kernel switches to kms.
After some downgrading some packages (linux-firmware, mesa, ...) I found out, that the kernel package (at the time 3.10.5) was the bad guy.
Now that kernel 3.11 is entering archlinux, I tried that today - with the same screen corruption result.
When I reverted the kernel package to 3.10.2 the system works as expected - no screen corruptions.
I made some <real> screenshots while booting on console:
Boot Screen
and KDE:
KDE Screen
If someone would like to look at the kernel output:
dmesg output
Now I'm at a point where I'm glue less how to solve this issue...
Offline
[ 0.000000] Your BIOS doesn't leave a aperture memory hole
[ 0.000000] Please enable the IOMMU option in the BIOS setup
If you're running a 32-bit kernel, this can be ignored.
For a 64-bit kernel on linux however, having IOMMU disabled tends to have very bad results.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Online
Thanks for your reply.
For a 64-bit kernel on linux however, having IOMMU disabled tends to have very bad results.
I don't have the ability to turn on the IOMMU inside the BIOS :-(
I tried the kernel parameters iommu=noaperture, iommu=force, iommu=allowdac with no luck (Same result). Maybe you can suggest some other things?
Last edited by Logiarch (2013-09-06 18:33:28)
Offline
I have a similar problem. Though it only occurs when I load the GPU, like hardware acceleration in VLC, or games. Could be the exact same problem. Last time I was in Arch was with Linux 3.9.x, and I came back during 3.10.9.
Offline
Logiarch, i've looked a bit deeper into the dmesg, and may have been wrong about the IOMMU message causing your problems.
[ 2.057464] [drm] initializing kernel modesetting (RS880 0x1002:0x9715 0x1849:0x9715).
<snip>
[ 2.059736] [drm] Loading RS780 Microcode
Your videocard is detected as a RS880/HD4200 type, but the firmware it loads is for the RS780/HD3200 cards.
This seems weird.
I suggest you compare the IOMMU & RSx80 messages in dmesg from the corruted graphics kernel AND dmesg from the working kernel.
another thing, probably unrelated to the graphics corruption :
in the lines from systemd , there are several services that are failing to start (dcronie service is one of them) , you should check your setup.
Xeekei : logiarch has very different symptoms as his problems appear way before X is started.
Imo you should start a new thread and include xorg0.log .
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Online
Xeekei : logiarch has very different symptoms as his problems appear way before X is started.
Imo you should start a new thread and include xorg0.log .
I posted this: https://bbs.archlinux.org/viewtopic.php?id=169312 Probably in the wrong section though. I'll look for that xorg0.log and add that.
Offline
Hi Lone_Wolf!
Thanks for taken time for my individual problem!
Logiarch, i've looked a bit deeper into the dmesg, and may have been wrong about the IOMMU message causing your problems.
[ 2.057464] [drm] initializing kernel modesetting (RS880 0x1002:0x9715 0x1849:0x9715). <snip> [ 2.059736] [drm] Loading RS780 Microcode
Your videocard is detected as a RS880/HD4200 type, but the firmware it loads is for the RS780/HD3200 cards.
This seems weird.I suggest you compare the IOMMU & RSx80 messages in dmesg from the corruted graphics kernel AND dmesg from the working kernel.
Both kernels suggests to enable iommu on BIOS.
Your BIOS doesn't leave a aperture memory hole
Please enable the IOMMU option in the BIOS setup
Both kernel loads the RS780 Microcode
Loading RS780 Microcode
I can't see real differences between the drm init routines, only the version changes (as expected ):
[drm] Initialized radeon 2.34.0 (not working) vs.[drm] Initialized radeon 2.33.0 (working)
I did some git bisect between kernel version v3.10.2 and v3.10.5 today and found the commit which causes this behavior:
6f8bbaf568c7f2c497558bfd04654c0b9841ad57 is the first bad commit
commit 6f8bbaf568c7f2c497558bfd04654c0b9841ad57
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Tue Jul 30 00:22:53 2013 -0400
drm/radeon/atom: initialize more atom interpretor elements to 0
commit 42a21826dc54583cdb79cc8477732e911ac9c376 upstream.
The ProcessAuxChannel table on some rv635 boards assumes
the divmul members are initialized to 0 otherwise we get
an invalid fb offset since it has a bad mask set when
setting the fb base. While here initialize all the
atom interpretor elements to 0.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=60639
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
:040000 040000 d2bb057047f71419a89def40e6e21dc948c5784c 7e49987ae73078e644723f0cb6c791e15e102ab0 M drivers
Hm, I try to build the linux3.11 kernel without this patch and check out if this would work.
The patch doesn't seems complicated, but fails (on my system).
Edit: It works.
Last edited by Logiarch (2013-09-07 20:05:44)
Offline
nice catch, Logiarch .
It seems that patch not only doesn't fix the problem in #60639, but zeroes out something that's needed for your system to work correctly.
I suggest you open a new kernel bug, point to #60639 and add alex deucher & greg Koah-Hartmann to the cc list for the new bug.
supplying xorg0.log , dmesg for both working / non working kernel would also be good.
Xeekei, i've reported your thread for moving it to this subboard.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Online