[Medion MS-7616] [drm:amdgpu_init [amdgpu]] *ERROR* VGACON disables amdgpu kernel modesetting.

Bug #1818580 reported by elhoir on 2019-03-05
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)

Bug Description

I cannot boot PC normally, i must use recovery mode.

Full dmesg after modprobe'ing amdgpu demonstrating call trace and lead up:

WORKAROUND: Use kernel parameter:

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: xserver-xorg-video-amdgpu 18.1.99+git20190207-1
ProcVersionSignature: Ubuntu 5.0.0-7.8-lowlatency 5.0.0
Uname: Linux 5.0.0-7-lowlatency x86_64

ApportVersion: 2.20.10-0ubuntu21
Architecture: amd64
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: None
CurrentDesktop: XFCE
Date: Tue Mar 5 00:59:48 2019
DistUpgraded: 2019-02-07 01:41:15,390 DEBUG Running PostInstallScript: './xorg_fix_proprietary.py'
DistroCodename: disco
DistroVariant: ubuntu
 Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X] [1002:67df] (rev cf) (prog-if 00 [VGA controller])
   Subsystem: PC Partner Limited / Sapphire Technology Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] [174b:353e]
InstallationDate: Installed on 2012-02-27 (2562 days ago)
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
MachineType: MEDIONPC MS-7616
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-7-lowlatency root=UUID=cded073e-f845-4947-970b-f8a4290c4c2b ro quiet splash acpi_osi=Linux nomodeset crashkernel=384M-:128M crashkernel=384M-2G:128M,2G-:256M crashkernel=512M-:192M vt.handoff=1
SourcePackage: xserver-xorg-video-amdgpu
UpgradeStatus: Upgraded to disco on 2019-02-07 (25 days ago)
dmi.bios.date: 01/15/2010
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: A7616MLN.10F
dmi.board.asset.tag: To Be Filled By O.E.M.
dmi.board.name: MS-7616
dmi.board.vendor: MEDIONPC
dmi.board.version: 1.0
dmi.chassis.type: 3
dmi.chassis.vendor: MEDIONPC
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrA7616MLN.10F:bd01/15/2010:svnMEDIONPC:pnMS-7616:pvr1.0:rvnMEDIONPC:rnMS-7616:rvr1.0:cvnMEDIONPC:ct3:cvr:
dmi.product.family: To Be Filled By O.E.M.
dmi.product.name: MS-7616
dmi.product.sku: To Be Filled By O.E.M.
dmi.product.version: 1.0
dmi.sys.vendor: MEDIONPC
version.compiz: compiz 1:
version.libdrm2: libdrm2 2.4.97-1
version.libgl1-mesa-dri: libgl1-mesa-dri 18.3.4-1ubuntu1
version.libgl1-mesa-glx: libgl1-mesa-glx 18.3.4-1ubuntu1
version.xserver-xorg-core: xserver-xorg-core 2:1.20.3-1ubuntu1
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.1.99+git20190207-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20180925-2
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

elhoir (jfarroyo82) wrote :
elhoir (jfarroyo82) on 2019-03-05
affects: xserver-xorg-video-amdgpu (Ubuntu) → linux (Ubuntu)

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed

What's the symptom when you remove all the kernel parameters?

elhoir (jfarroyo82) wrote :

@Kai-Heng Feng (kaihengfeng)

No change, same behavior. I removed all parameters except "ro"

Kai-Heng Feng (kaihengfeng) wrote :

Have you tried -generic kernel instead of -lowlatency?

elhoir (jfarroyo82) wrote :

nope i didnt.... lets test now

elhoir (jfarroyo82) wrote :

@Kai-Heng Feng (kaihengfeng)

NO change again, same behavior with -generic kernel


1) It looks like you installed Ubuntu originally with 11.10, and then upgraded all the way to 19.04. To clarify, have you always had to use the kernel parameter nomodeset to boot since 11.10?

2) With all of the following kernel parameters removed (and any WORKAROUND or other non-default also removed), could you please provide the missing logs from a bad boot following https://wiki.ubuntu.com/DebuggingKernelBoot ?

quiet splash acpi_osi=Linux nomodeset crashkernel=384M-:128M crashkernel=384M-2G:128M,2G-:256M crashkernel=512M-:192M vt.handoff=1

description: updated
Changed in linux (Ubuntu):
importance: Undecided → Low
status: Confirmed → Incomplete
tags: added: latest-bios-1.0f
summary: - [drm:amdgpu_init [amdgpu]] *ERROR* VGACON disables amdgpu kernel
- modesetting.
+ [Medion MS-7616] [drm:amdgpu_init [amdgpu]] *ERROR* VGACON disables
+ amdgpu kernel modesetting.
elhoir (jfarroyo82) wrote :


1) No, never, but i never used amdgpu driver before, only radeonsi or nouveau. I remember some kernel working fine some days ago but i cant remember which one...

2) will do it asap, im not at home now...

elhoir (jfarroyo82) wrote :

probably an off-topic question... what is VGACON ???

elhoir (jfarroyo82) wrote :

Sorry but i have no way to get those logs. Boot gets frozen, i have to dirty shutdown via power button. And now in Windows the Ext4 filesystem is unclean so i cant mount it to get logs from /var/log

any idea?


Regarding your comment https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1818580/comments/9 :
>" No, never, but i never used amdgpu driver before"

I'm afraid this didn't answer my question. Which release precisely did you have to start using nomodeset to boot?

Regarding your comment https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1818580/comments/9 :
>"...only radeonsi or nouveau."

To advise, nouveau is used for nvidia cards. Did you swap out/in a nvidia card at some point?

Regarding your comment https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1818580/comments/11 :
>"Boot gets frozen..."

To clarify, you followed verbatim https://wiki.ubuntu.com/DebuggingKernelBoot#Capture_information_from_a_bad_boot_and_post_to_your_bug_report and while recording video with a cell phone or video recorder there is nothing on the screen from startup all the way to boot is frozen?

Regarding your comment https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1818580/comments/11 :
>"...so i cant mount it to get logs from /var/log"

You may want to try using a live environment via http://cdimage.ubuntu.com/daily-live/current/ as this will provide a fresh boot versus one that may have upgrade cruft left over, and help rule some things out.

elhoir (jfarroyo82) wrote :

1) only latest, Disco Dingo

2) yes, i have few nvidia/ati/amd cards here, so i swapped them

3) i did not record any video, will do it next time i boot into Linux

4) ok, will try

Kai-Heng Feng (kaihengfeng) wrote :

Please add kernel parameter "blacklist=amdgpu", and boot with mainline kernel.
Once you can use shell, run `modprobe amdgpu` to see if any trace/panic can be seen. You may want to use SSH to do this.

elhoir (jfarroyo82) wrote :

well, this is surprising and unexpected

MY boot cmdline is:

linux 5.0.0-7-lowlatency ro blacklist=amdgpu

And even with that i can not boot normally!

The worst part is that network is not up yet so i cant use SSH :/

tags: added: needs-debug-logs regression-potential
Kai-Heng Feng (kaihengfeng) wrote :

Ok, then use kernel parameter "blacklist=amdgpu modprobe.blacklist=amdgpu".

SSH to the system, then run `sudo modprobe amdgpu`.

elhoir (jfarroyo82) wrote :
Download full text (4.1 KiB)

okay, the "modprobe.blacklist=amdgpu" parameter did work.

Now at SSH:

elhoir@elhoir-desktop:~$ sudo modprobe amdgpu
[sudo] contraseña para elhoir:

No errors.

elhoir@elhoir-desktop:~$ lsmod
Module Size Used by
amdgpu 3567616 2
chash 16384 1 amdgpu
amd_iommu_v2 20480 1 amdgpu
gpu_sched 32768 1 amdgpu
ttm 102400 1 amdgpu
drm_kms_helper 180224 1 amdgpu
drm 475136 6 gpu_sched,drm_kms_helper,amdgpu,ttm
i2c_algo_bit 16384 1 amdgpu
fb_sys_fops 16384 1 drm_kms_helper
syscopyarea 16384 1 drm_kms_helper
sysfillrect 16384 1 drm_kms_helper
sysimgblt 16384 1 drm_kms_helper
pci_stub 16384 1
vboxpci 24576 0
vboxnetadp 28672 0
vboxnetflt 28672 0
vboxdrv 450560 3 vboxpci,vboxnetadp,vboxnetflt
r8188eu 434176 0
lib80211 16384 1 r8188eu
cfg80211 679936 1 r8188eu
joydev 24576 0
snd_hda_codec_hdmi 53248 1
snd_hda_intel 45056 2
snd_hda_codec 126976 2 snd_hda_codec_hdmi,snd_hda_intel
snd_ctxfi 114688 2
snd_hda_core 81920 3 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec
snd_hwdep 20480 1 snd_hda_codec
snd_pcm 102400 5 snd_ctxfi,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_core
snd_seq_midi 20480 0
snd_seq_midi_event 16384 1 snd_seq_midi
snd_rawmidi 36864 1 snd_seq_midi
snd_seq 69632 2 snd_seq_midi,snd_seq_midi_event
snd_seq_device 16384 3 snd_seq,snd_seq_midi,snd_rawmidi
snd_timer 36864 2 snd_seq,snd_pcm
snd 81920 18 snd_ctxfi,snd_seq,snd_seq_device,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_timer,snd_pcm,snd_rawmidi
soundcore 16384 1 snd
input_leds 16384 0
mac_hid 16384 0
serio_raw 20480 0
intel_powerclamp 20480 0
intel_cstate 20480 0
kvm_intel 245760 0
kvm 634880 1 kvm_intel
irqbypass 16384 1 kvm
ip6t_REJECT 16384 3
nf_reject_ipv6 20480 1 ip6t_REJECT
nf_log_ipv6 16384 5
xt_hl 16384 22
ip6t_rt 20480 3
binfmt_misc 24576 1
sch_fq_codel 20480 5
ipt_REJECT 16384 3
nf_reject_ipv4 16384 1 ipt_REJECT
nf_log_ipv4 16384 5
nf_log_common 16384 2 nf_log_ipv4,nf_log_ipv6
xt_LOG 20480 10
xt_limit 16384 13
xt_tcpudp 20480 29
xt_addrtype 16384 4
xt_conntrack 16384 16
ip6table_filter 16384 1
ip6_tables 32768 53 ip6table_filter
nf_conntrack_netbios_ns 16384 0
nf_conntrack_broadcast 16384 1 nf_conntrack_netbios_ns
nf_nat_ftp 20480 0
nf_nat 36864 1 nf_nat_ftp
nf_conntrack_ftp 24576 1 nf_nat_ftp
nf_conntrack 135168 6 xt_conntrack,nf_nat,nf_nat_ftp,nf_conntrack_netbios...


elhoir (jfarroyo82) wrote :
elhoir (jfarroyo82) wrote :

iḿ getting this logs in dmesg, maybe after trying to load amgpu with "sudo modprobe amdgpu"?

elhoir (jfarroyo82) wrote :

yes, system is totally messed up locally, still usable via SSH through


Regarding the dmesg posted in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1818580/comments/20 did you cut/snip it? Please ensure all logs are attached in their entirety (no cuts, snips, etc.).

To confirm a regression, regarding only the current AMD graphics card installed, what prior Ubuntu releases and prior kernel versions have you tested specifically, and did they require any WORKAROUNDs?

tags: added: kernel-bug-exists-upstream kernel-bug-exists-upstream-5.0
removed: regression
elhoir (jfarroyo82) wrote :

1) yes, its a copy paste of crash part of dmesg, not entire output.

2) well i cant test it, as its the 1st time im using amdgpu module, asi said.
Previously i only used radeinsi and nouveau modules, my GPU (RX 470) is quite new.
I tested Ubuntu Cosmic and Ubuntu Dingo.

And no, none did require any workaround.

Kai-Heng Feng (kaihengfeng) wrote :

Log in #20 is really useful.

Please file an upstream bug at https://bugs.freedesktop.org/
Product: DRI
Component: DRM/AMDgpu

And attach the log in #20. Thanks!

elhoir (jfarroyo82) wrote :

@Kai-Heng Feng (kaihengfeng)

done. https://bugs.freedesktop.org/show_bug.cgi?id=109924

elhoir (jfarroyo82) on 2019-03-07
description: updated
elhoir (jfarroyo82) wrote :


"However, while using Dingo after a kernel update, Dingo stopped booting without a WORKAROUND?"
Yes, thatś right

"which kernel update specifically?"
Can not say. I have tested 4.18 and 4.20, both fail.

elhoir (jfarroyo82) wrote :

this is the complete uncut dmesg output right after "sudo modprobe amdgpu"

description: updated
tags: added: needs-bisect regression-update
removed: regression-potential
tags: removed: needs-debug-logs

elhoir, the next step is to fully commit bisect from Ubuntu kernel 4.19.0-7.8 to Ubuntu kernel 5.0.0-7.8. This will allow for a direct review of the offending commit(s) for either reverting, or further improvements. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection ? This article was written for folks who don't know anything about linux, so it's easy to follow.

Please note, finding adjacent kernel versions, or providing a commit without testing it and reverting it is not fully commit bisecting.

Also, the kernel release names are irrelevant for the purposes of bisecting.

It is most helpful that after the bad commit (not kernel version) has been confirmed via testing, you then mark this report Status Confirmed.

Thank you for your help.

elhoir (jfarroyo82) wrote :

this will take time for me... im really noob and i have never bisected anything, not to say a kernel xD

elhoir (jfarroyo82) wrote :

@christopher, are you sure 4.19.0-7.8 works? how could i test it?

elhoir (jfarroyo82) wrote :

ok, i saw it, 4.19.0-7.8 corresponds to 4.19.5 mainline

elhoir (jfarroyo82) wrote :

i`m afraid kernel 4.19.0-7.8 does NOT work.
Here is the complete mesg output for that kernel

elhoir (jfarroyo82) wrote :



Please ensure you are not using non-default kernel parameters. As per most recent dmesg remove:
acpi_osi=Linux modprobe.blacklist=amdgpu crashkernel=384M-:128M crashkernel=384M-2G:128M,2G-:256M crashkernel=512M-:192M crashkernel=512M-:192M crashkernel=512M-:192M

Keep testing successively newer kernels, until you either find one that does boot, or reach Ubuntu kernel 5.0.0-7.8.

elhoir (jfarroyo82) wrote :

for 1) No change, even with only "ro" parameter

i'm getting annoyed and frustrated....

Kai-Heng Feng (kaihengfeng) wrote :

Please just wait for AMDGPU maintainer's response. We can't do much now.

elhoir, while you are welcome to wait for whenever a maintainer may respond, given this issue has been reported a regression, it is known that it helps developers expedite a fix if the offending commit(s) are identified via bisect.

elhoir (jfarroyo82) wrote :

I agree, but i cannot find a working scenario to start with


>"but i cannot find a working scenario to start with"

To clarify, you stepped through all the Ubuntu kernel versions from 4.19.0-7.8 to 5.0.0-7.8 and the problem is still reproducible?

If so, stepping through versions older than 4.19.0-7.8 until a working state is found would be next.

elhoir (jfarroyo82) wrote :


i have even tested 4.11(.12) kernel, which i have seen reported as the 1st kernel in which RX470 works. And it doesnt in my hardware

Its really annoying

elhoir (jfarroyo82) wrote :

i also tested previous linux-firmware package (from Bionic, 1.173.3), and previous xserver-xorg-video-amdgpu 8.1.0 package

All of them fail.

elhoir (jfarroyo82) wrote :

btw, i have checked that kernel is not completely halted. R-E-I-S-U-B key sequence still works for rebooting system.

elhoir, if its actually true you personally were able to boot using the RX470 without WORKAROUNDs, its possible that either when you are installing older kernels you aren't installing the correct packages, or you were mistaken and it only booted either with a WORKAROUND or when a different graphics card was installed.

Unless the above may be confirmed, one is at the mercy of whomever has your hardware to confirm a regression.

Changed in linux (Ubuntu):
status: Incomplete → Triaged
tags: added: regression-potential
removed: regression-update
elhoir (jfarroyo82) wrote :

i contacted with a guy with an AMD RX 470 GPU and he says irs working fine on his system

i have just tested 18.10 and a daily 19.04 livecd builds with no success. Also i have disabled ACPI in both BIOS and kernel cmdlive (acpi=off) with no success

elhoir (jfarroyo82) wrote :



>"i contacted with a guy with an AMD RX 470 GPU and he says irs working fine on his system"

Besides mundane root causes (card hardware jacked and needs RMA), there are other reason why your results differ from others (not all RX 470 cards are equivalent in every way due to OEM implementation differences, firmware on the card itself differing, the root cause is due to both the card and the hardware its plugged into, different operating system environments, etc.).

elhoir (jfarroyo82) wrote :


latest kernel 5.1.0 (lowlatency) from


Seems to have solved the issue, as i have started Ubuntu with no problems with amdgpu module loaded.

tags: added: needs-reverse-bisect
tags: added: kernel-fixed-upstream-5.1
removed: kernel-bug-exists-upstream needs-bisect
Tom Reynolds (tomreyn) wrote :

The "[drm:amdgpu_init [amdgpu]] *ERROR* VGACON disables amdgpu kernel modesetting." was also reported in bug 1837945 where kernel / boot parameter "amdgpu.dc=0" worked around an otherwise boot to black screen. There, however, Linux versions 5.1 and 5.2 would also not work with this parameter set.

elhoir (jfarroyo82) wrote :

"Linux versions 5.1 and 5.2 would also not work with this parameter set."

well i have been running 5.1.10 successfully.... Now in windows, and next time i boot into Linux i will be using 5.1.20... Let´s see what happens then...

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.