[SOLVED] xf86-video-ati with KMS: mostly black screen, sometimes it...

Rootsquash · 2016-01-23 11:30:36

[SOLVED] booting with radeon.dpm=0 works reliably

Hi, some time ago I've upgraded my graphics card to a HD6000 series, I think it's this one: https://www.asus.com/Graphics-Cards/EAH … /overview/

It works great with Windows and (sometimes) works great with Linux, but usually Linux won't boot (with KMS enabled, which is required for xf86-video-ati).
I usually give up after ~5 tries. Sometimes it works on the first try, sometimes on the second try (and so on), but more often then not I just end up booting Windows.
The actual symptoms (and error messages) vary:

Screen:
mostly: monitor turns off
sometimes: black screen, cursor in top left corner
rarely: CTRL+ALT+F1 brings up the console, showing something like "[ 152.393273] radeon 0000:01:00.0: GPU lockup (current fence id 0x0000000000000001 last fence id 0x0000000000000003 on ring 3)
[ 152.893008] radeon 0000:01:00.0: ring 3 stalled for more than 10500msec
[ 152.893019] radeon 0000:01:00.0: GPU lockup (current fence id 0x0000000000000001 last fence id 0x0000000000000003 on ring 3)
[ 153.392771] radeon 0000:01:00.0: ring 3 stalled for more than 11000msec"

Sometimes the system responds to pressing Numlock by triggering the Numlock-LED, sometimes it doesn't.
Sometimes I can reboot with CTRL+ALT+DEL, sometimes I can't.

Hardware involved: Monitor is attached via DP: I used DVI, then switched to DP to see if it would fix the issue. (it didn't)
Mainboard: ASUS M4A78T-E with HD3300 Onboard-GPU (disabled in BIOS).
I also tried to use the HD3300 with Linux and restrict usage of the HD6xxx to Windows, but even with the HD3300 as the primary display adapter Linux will hang.

I have deleted my custom X settings:
~ ls /etc/X11/xorg.conf.d/
00-keyboard.conf

and tried adding different options to Grub, which apparently solved other peoples problems that I stumbled upon while searching the internet for symptoms and error-messages. Current state:
GRUB_CMDLINE_LINUX_DEFAULT="radeon.runpm=0" (doesn't really help)

Early modesetting (adding radeon-module to mkinitcpio) seems to make matters worse, as the monitor will turn off immediately.

I have no idea which logs I should attach, so as a start I'll post a link to some syslog-ng-output of a recent failed boot:
http://pastebin.com/K6wTBkxw

Can anyone help me pinpoint (and maybe even solve) the problem?

"Rootsquash"

Last edited by Rootsquash (2016-03-12 09:25:08)

Lone_Wolf · 2016-01-23 15:36:35

Jan 21 19:37:39 trillian kernel: [    0.000000] AGP: Your BIOS doesn't leave an aperture memory hole
Jan 21 19:37:39 trillian kernel: [    0.000000] AGP: Please enable the IOMMU option in the BIOS setup

You are running x86_64 system for both linux and windows ?

if so, check your bios / firmware for options related to IOMMU, Virtualization ,etc .
(no clue how asus calls them)

Last edited by Lone_Wolf (2016-01-23 15:37:22)

Rootsquash · 2016-01-23 17:02:33

Hi,

yes, I'm using x86_64 versions of Linux and Windows.

This ASUS -Mainboard wasn't the cheapest on the market, but there are next to none virtualization options in the BIOS and I can't find anything with IOMMU in the description.
Apparently I'm not the first to look for this option: http://vip.asus.com/forum/view.aspx?id= … uage=en-us
I found Secure Virtual Machine Mode [Enabled] in the CPU options and Location of Frame Buffer [Above 4G].
I also found some Link ASPM option for the PCIE-connections, currently set to [Disabled].

/e: I tried booting with kernel parameter iommu=noaperture, which worked 2 times in a row. I'm hopeful and will keep testing

Last edited by Rootsquash (2016-01-23 17:13:17)

Rootsquash · 2016-01-23 17:49:43

And on the third try it went wrong again. Log: http://pastebin.com/Kccb5Eeg

Lone_Wolf · 2016-01-24 12:43:40

Secure Virtual Machine Mode & Location of framebuffer do matter for IOMMU/x86_64 functionality.

Are you using early kms (modules=radeon in mkinitcpio.conf ) or late kms start ?
try switching to the other method.

Oh, and before i forget to ask : You are using latest firmware for your motherboard ?

Rootsquash · 2016-01-26 18:19:02

Hi, I'm currently using late KMS, as early KMS just makes the display turn off even faster.

I'll try playing around with the framebuffer and SVM settings and double-check the BIOS-Version.

/e: I could just boot Linux ~7 times in a row, without changing anything. I'm still not convinced though: Murphy will get you every time. (Shouldn't computers be deterministic?)

Last edited by Rootsquash (2016-01-26 19:36:14)

Rootsquash · 2016-02-14 09:43:32

And I was right: After about 10 successful boots, it didn't start about 10 times in a row.
I've tried to boot Arch again and again in the last days, but it rarely works.

And yes: I may have updated with pacaur -Suy, but I guess this shouldn't be a problem since the hardware is quite old and the drivers shouldn't change much (sddm is disabled to avoid problems with OpenGL and other graphics stuff)

I really don't know what to do next. If anyone has an idea: please let me know, thanks

Lone_Wolf · 2016-02-14 14:44:10

http://www.x.org/wiki/radeonBuildHowTo/ wrote:

Hints to dig deeper into radeon-KMS problems on startup
If you can't boot with KMS enabled the easiest way to debug problems is to boot into runlevel-3 (text console, VT) with KMS disabled or blacklist the radeon kernel-module. Then try to unload/load drm and radeon kernel-modules via modprobe commands (preferable over ssh and from a second machine).
Booted into runlevel-3 (grub-line: Append "radeon.modeset=0" means KMS disabled):
modprobe -r -v drm radeon <--- Unload drm and radeon kernel-module (-r: remove, -v: verbose)
modprobe -v drm debug=1 <--- Additional for debugging DRM issues (maximum debug-level is 15)
modprobe -v radeon modeset=1 <--- Load radeon kernel-module with KMS support

instead of runlevel 3 , use multi-user.target .

Rootsquash · 2016-02-16 10:42:00

Hi,

as soon as I load the radeon module the screen goes blank and the ssh-connection freezes:
http://pastebin.com/JwqsMSeE

The other modules (drm_kms_helper, ttm, syscopyarea, sysfillrect, sysimgblt, fb_sys_fops) seem to load fine.

Lone_Wolf · 2016-02-16 13:47:08

the drm module normally loads firmware blobs for videocards, but the log shows nothing like that.

let's try the following :

modprobe --verbose --remove drm radeon
modprobe --verbose --dry-run drm
save logs ( dmesg or journalctl -b) & terminal output
modprobe --verbose drm
save logs
modprobe --verbose --dry-run radeon
save logs

Post the logs, doing it this way should give us useful info without you getting the black screen / freezing.

WFV · 2016-02-17 00:06:32

Have you tried the generic driver instead of ati? My M5A88-M starts on the generic driver then hands off to radeon later in the boot. (from journalctl log)

fb: switching to radeondrmfb from VESA VGA

I've tried the different chip settings and ram settings including disabling memory hole remapping in the bios to clear the iommu message and have svm enabled (because VirtualBox won't run without it and I have some virtual machines) and nothing removed that message including adjusting the framebuffer - i leave it at max now with new gpu card (>4GB) however, GART writes an aperture over the ram later in the boot and does the iommu task that the initial AGP err'd on, so for the M5A88-M (very similar machine to the M4A78's) I decided it's no problem.
Also tried the iommu=noagp,noaperture in grub and made no difference, for now I have grub set to:

GRUB_CMDLINE_LINUX_DEFAULT="quiet radeon.dpm=1"

Haven't tried radeon in mkinitcpio yet. I switched from the integrated graphics to a pci card couple months ago only because Asus has a support cutoff for drivers <6000 series (my igfx is 4200 series and the gfx0 is 7000 series).

Last edited by WFV (2016-02-21 00:03:43)

Rootsquash · 2016-02-19 09:54:17

Lone_Wolf wrote:

the drm module normally loads firmware blobs for videocards, but the log shows nothing like that.
let's try the following :
[...]
Post the logs, doing it this way should give us useful info without you getting the black screen / freezing.

HI, I'm afraid I've done something stupid, as I don't get any useful logs:

[trillian ~ #] modprobe --verbose --remove drm_kms_helper
rmmod drm_kms_helper
rmmod fb_sys_fops
rmmod sysimgblt
rmmod sysfillrect
rmmod syscopyarea
[trillian ~ #] modprobe --verbose --remove ttm
rmmod ttm
rmmod drm
[trillian ~ #] modprobe --verbose --remove drm
[trillian ~ #] echo "##### modprobe --verbose --dry-run drm " >> /dev/kmsg
[trillian ~ #] modprobe --verbose --dry-run drm
insmod /lib/modules/4.4.1-2-ARCH/kernel/drivers/gpu/drm/drm.ko.gz
[trillian ~ #] echo "##### modprobe --verbose drm " >> /dev/kmsg
[trillian ~ #] modprobe --verbose drm
insmod /lib/modules/4.4.1-2-ARCH/kernel/drivers/gpu/drm/drm.ko.gz
[trillian ~ #] echo "##### modprobe --verbose --dry-run radeon " >> /dev/kmsg
[trillian ~ #] modprobe --verbose --dry-run radeon
insmod /lib/modules/4.4.1-2-ARCH/kernel/drivers/video/fbdev/core/fb_sys_fops.ko.gz
insmod /lib/modules/4.4.1-2-ARCH/kernel/drivers/video/fbdev/core/sysimgblt.ko.gz
insmod /lib/modules/4.4.1-2-ARCH/kernel/drivers/video/fbdev/core/sysfillrect.ko.gz
insmod /lib/modules/4.4.1-2-ARCH/kernel/drivers/video/fbdev/core/syscopyarea.ko.gz
insmod /lib/modules/4.4.1-2-ARCH/kernel/drivers/gpu/drm/drm_kms_helper.ko.gz
insmod /lib/modules/4.4.1-2-ARCH/kernel/drivers/gpu/drm/ttm/ttm.ko.gz
insmod /lib/modules/4.4.1-2-ARCH/kernel/drivers/gpu/drm/radeon/radeon.ko.gz runpm=0 modeset=0
[trillian ~ #] dmesg|tail -n 20
[ 3.106851] kvm: Nested Paging enabled
[ 3.270340] Adding 4194300k swap on /dev/sdb3. Priority:-1 extents:1 across:4194300k SSFS
[ 3.277611] fuse init (API version 7.23)
[ 3.334421] EXT4-fs (sdb2): mounting ext2 file system using the ext4 subsystem
[ 3.340027] EXT4-fs (sdb2): mounted filesystem without journal. Opts: (null)
[ 3.350598] EXT4-fs (sdb5): mounted filesystem without journal. Opts: acl,user_xattr
[ 3.414587] EXT4-fs (sdb6): mounted filesystem with ordered data mode. Opts: acl,user_xattr
[ 3.465077] systemd-journald[195]: Received request to flush runtime journal from PID 1
[ 3.624962] microcode: CPU0: new patch_level=0x010000db
[ 3.624973] microcode: CPU1: new patch_level=0x010000db
[ 3.624985] microcode: CPU2: new patch_level=0x010000db
[ 3.624994] microcode: CPU3: new patch_level=0x010000db
[ 3.689258] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 5.500552] mousedev: PS/2 mouse device common for all mice
[ 5.528733] ATL1E 0000:03:00.0 eth0: NIC Link is Up <1000 Mbps Full Duplex>
[ 5.528745] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 64.043637] ##### modprobe --verbose --dry-run drm
[ 64.048997] ##### modprobe --verbose drm
[ 64.066146] [drm] Initialized drm 1.1.0 20060810
[ 64.071550] ##### modprobe --verbose --dry-run radeon
[trillian ~ #] tail -n 20 /var/log/everything.log
Feb 19 11:50:27 trillian ntpd[768]: new interface(s) found: waking up resolver
Feb 19 10:50:33 trillian systemd[1]: Time has been changed
Feb 19 10:50:37 trillian dhcpcd[880]: eth0: no IPv6 Routers available
Feb 19 10:50:43 trillian systemd[1]: Created slice User Slice of luda.
Feb 19 10:50:43 trillian systemd[1]: Starting User Manager for UID 1000...
Feb 19 10:50:43 trillian systemd[1]: Started Session c1 of user luda.
Feb 19 10:50:43 trillian systemd[891]: Listening on Sound System.
Feb 19 10:50:43 trillian systemd[891]: Starting D-Bus User Message Bus Socket.
Feb 19 10:50:43 trillian systemd[891]: Reached target Paths.
Feb 19 10:50:43 trillian systemd[891]: Reached target Timers.
Feb 19 10:50:43 trillian systemd[891]: Listening on D-Bus User Message Bus Socket.
Feb 19 10:50:43 trillian systemd[891]: Reached target Sockets.
Feb 19 10:50:43 trillian systemd[891]: Reached target Basic System.
Feb 19 10:50:43 trillian systemd[891]: Reached target Default.
Feb 19 10:50:43 trillian systemd[891]: Startup finished in 52ms.
Feb 19 10:50:43 trillian systemd[1]: Started User Manager for UID 1000.
Feb 19 10:51:21 trillian ##### modprobe --verbose --dry-run drm
Feb 19 10:51:21 trillian ##### modprobe --verbose drm
Feb 19 10:51:21 trillian kernel: [drm] Initialized drm 1.1.0 20060810
Feb 19 10:51:21 trillian ##### modprobe --verbose --dry-run radeon
[trillian ~ #]

Rootsquash · 2016-02-19 10:09:23

WFV wrote:

GRUB_CMDLINE_LINUX_DEFAULT="quiet radeon.dpm=1"

I have tried radeon.runpm=0, changed that to radeon.dpm=0 and it booted a couple of times. I'll probably post an aupdate soon

Last edited by Rootsquash (2016-02-19 10:10:08)

Lone_Wolf · 2016-02-19 12:59:53

looks like i messed up important parameters in the commands.

1.
a. remove drm & radeon kernelmodules
#modprobe --remove drm radeon

b. verify drm & radeon have been succesfully removed
# lsmod | grep drm
# lsmod | grep radeon

c. post last line of log so we'll know the timestamp

2.
a. install drm module
#modprobe --verbose drm debug=7

b. post last line of log for timestamp

3.
a. # modprobe --verbose --dry-run radeon modeset=1

b. post last line of log for timestamp

4.
pastebin the full log

Rootsquash · 2016-03-12 09:23:12

Oh, I seem to have missed your last post, I'm going to try these steps now.

But first: using radeon.dpm=0 works. As long as I turn on my monitor before X starts, my PC boots. I guess I should mark this thread as solved.

Rootsquash · 2016-03-12 09:50:23

Full log (dmesg): http://pastebin.com/P8QRZg09

sh radeontest.sh
> modprobe --remove drm_kms_helper ttm drm radeon
> lsmod | grep drm
>lsmod | grep radeon
> modprobe --verbose drm debug=7
insmod /lib/modules/4.4.5-1-ARCH/kernel/drivers/gpu/drm/drm.ko.gz debug=7
> modprobe --verbose --dry-run radeon modeset=1 dpm=1
insmod /lib/modules/4.4.5-1-ARCH/kernel/drivers/video/fbdev/core/fb_sys_fops.ko.gz
insmod /lib/modules/4.4.5-1-ARCH/kernel/drivers/video/fbdev/core/sysimgblt.ko.gz
insmod /lib/modules/4.4.5-1-ARCH/kernel/drivers/video/fbdev/core/sysfillrect.ko.gz
insmod /lib/modules/4.4.5-1-ARCH/kernel/drivers/video/fbdev/core/syscopyarea.ko.gz
insmod /lib/modules/4.4.5-1-ARCH/kernel/drivers/gpu/drm/drm_kms_helper.ko.gz
insmod /lib/modules/4.4.5-1-ARCH/kernel/drivers/gpu/drm/ttm/ttm.ko.gz
insmod /lib/modules/4.4.5-1-ARCH/kernel/drivers/gpu/drm/radeon/radeon.ko.gz modeset=0 dpm=0 modeset=1 dpm=1
> dmesg|tail -n 1
[ 637.644906] [drm] Initialized drm 1.1.0 20060810
> dmesg > log.txt

I would have expected insmod to overwrite the old options instead of just appendig the new ones: "modeset=0 dpm=0 modeset=1 dpm=1"
Is this OK or do I have to blacklist the module(s), reboot and try again?

Arch Linux

#1 2016-01-23 11:30:36

[SOLVED] xf86-video-ati with KMS: mostly black screen, sometimes it...

#2 2016-01-23 15:36:35

Re: [SOLVED] xf86-video-ati with KMS: mostly black screen, sometimes it...

#3 2016-01-23 17:02:33

Re: [SOLVED] xf86-video-ati with KMS: mostly black screen, sometimes it...

#4 2016-01-23 17:49:43

Re: [SOLVED] xf86-video-ati with KMS: mostly black screen, sometimes it...

#5 2016-01-24 12:43:40

Re: [SOLVED] xf86-video-ati with KMS: mostly black screen, sometimes it...

#6 2016-01-26 18:19:02

Re: [SOLVED] xf86-video-ati with KMS: mostly black screen, sometimes it...

#7 2016-02-14 09:43:32

Re: [SOLVED] xf86-video-ati with KMS: mostly black screen, sometimes it...

#8 2016-02-14 14:44:10

Re: [SOLVED] xf86-video-ati with KMS: mostly black screen, sometimes it...

#9 2016-02-16 10:42:00

Re: [SOLVED] xf86-video-ati with KMS: mostly black screen, sometimes it...

#10 2016-02-16 13:47:08

Re: [SOLVED] xf86-video-ati with KMS: mostly black screen, sometimes it...

#11 2016-02-17 00:06:32

Re: [SOLVED] xf86-video-ati with KMS: mostly black screen, sometimes it...

#12 2016-02-19 09:54:17

Re: [SOLVED] xf86-video-ati with KMS: mostly black screen, sometimes it...

#13 2016-02-19 10:09:23

Re: [SOLVED] xf86-video-ati with KMS: mostly black screen, sometimes it...

#14 2016-02-19 12:59:53

Re: [SOLVED] xf86-video-ati with KMS: mostly black screen, sometimes it...

#15 2016-03-12 09:23:12

Re: [SOLVED] xf86-video-ati with KMS: mostly black screen, sometimes it...

#16 2016-03-12 09:50:23

Re: [SOLVED] xf86-video-ati with KMS: mostly black screen, sometimes it...

Board footer