Ubuntu 16.04 won't properly boot due to radeon module issue

Bug #1598935 reported by Tomdkat
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Expired
Low
Unassigned

Bug Description

When I boot an Ubuntu 16.04 live DVD on a Gateway system with an AMD A6-5400K APU, with an integrated Radeon HD 7540D graphics adapter, I get a black screen with no video image. If I look at "dmesg" output, I see these messages:
ubuntu@ubuntu:~$ dmesg | grep "UMS"
[ 4.827258] [drm:radeon_init [radeon]] *ERROR* No UMS support in radeon module!
[ 39.561534] [drm:radeon_init [radeon]] *ERROR* No UMS support in radeon module!
[ 76.905778] [drm:radeon_init [radeon]] *ERROR* No UMS support in radeon module!

We currently run Ubuntu 14.04.2 on the system with no issue, including using the "radeon" video driver.

WORKAROUND: Boot using kernel parameter:
nomodeset

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: linux-image-4.4.0-21-generic 4.4.0-21.37
ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6
Uname: Linux 4.4.0-21-generic x86_64
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC2: ubuntu 2057 F.... pulseaudio
 /dev/snd/controlC0: ubuntu 2057 F.... pulseaudio
 /dev/snd/controlC1: ubuntu 2057 F.... pulseaudio
CasperVersion: 1.376
Date: Mon Jul 4 20:08:04 2016
LiveMediaBuild: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
MachineType: Gateway DX4380G
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 EFI VGA
ProcKernelCmdLine: BOOT_IMAGE=/casper/vmlinuz.efi file=/cdrom/preseed/hostname.seed boot=casper quiet splash nomodeset ---
PulseList:
 Error: command ['pacmd', 'list'] failed with exit code 1: Home directory not accessible: Permission denied
 No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
 linux-restricted-modules-4.4.0-21-generic N/A
 linux-backports-modules-4.4.0-21-generic N/A
 linux-firmware 1.157
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 09/04/2012
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: P11-A1
dmi.board.name: DX4380G
dmi.board.vendor: Gateway
dmi.board.version: 1.02
dmi.chassis.type: 3
dmi.chassis.vendor: Gateway
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrP11-A1:bd09/04/2012:svnGateway:pnDX4380G:pvr:rvnGateway:rnDX4380G:rvr1.02:cvnGateway:ct3:cvr:
dmi.product.name: DX4380G
dmi.sys.vendor: Gateway

Revision history for this message
Tomdkat (tomdkat) wrote :
Revision history for this message
Tomdkat (tomdkat) wrote :

I'm also attaching the /var/log/Xorg.0.log file.

Thanks!

Revision history for this message
Brad Figg (brad-figg) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
penalvch (penalvch)
tags: added: bios-outdated-p12.a2
tags: added: regression-release
Revision history for this message
penalvch (penalvch) wrote :

Tomdkat, thank you for reporting this and helping make Ubuntu better.

Could you please provide the missing information following https://wiki.ubuntu.com/DebuggingKernelBoot ? Please don't grep anything when providing the information.

description: updated
Changed in linux (Ubuntu):
importance: Undecided → Low
status: Confirmed → Incomplete
Revision history for this message
Tomdkat (tomdkat) wrote :

Ok, attached is the output from "dmesg" after I booted from the Ubuntu 16.04 live DVD. Per the instructions here:

https://wiki.ubuntu.com/DebuggingKernelBoot

I changed "set gfxpayload=keep" to "set gfxpayload=text"

After doing that, the wireless network adapter didn't work. Previously, the wireless adapter did work but I left the "gfxpayload" setting to "keep". I'm using a wired Ethernet connection right now. I also replaced "quiet splash" with "nomodeset", since without "nomodeset", I won't get any video. There was no "vt.handoff" setting when I looked at the default kernel parameters screen.

Please let me know what other information you need.

Thanks!

Revision history for this message
penalvch (penalvch) wrote :

Tomdkat, to advise, posting with nomodeset makes the log useless.

You can try setting up SSH, so that when it boots up, even though the video is off, you may copy the log from the running machine.

Revision history for this message
Tomdkat (tomdkat) wrote :

Thanks for the reply. Well, if I'm not getting any video I'm not sure how I could get SSH setup but I do have something interesting to report. When I boot the live DVD, leave the "set gfxpayload=keep" setting alone, and remove "quiet splash" from the kernel parameters, I can get the system to boot. How? I'm not sure. I wait for there to be no sound from the optical drive, which tells me the system has completed its internal boot process. Then I start pressing Ctrl-Alt-F1 through F12, trying to switch from X terminal sessions to a text-mode login session and eventually, I'll get a video signal, along with the desktop on the terminal I get from Ctrl-Alt-F7 (tty 7). So, perhaps I'm triggering something by doing this, I'm not sure.

However, I do have a dmesg log generated *without* specifying "nomodeset".

Now, something else worth mentioning. I have the system setup to *not* boot in UEFI mode, because I had problems with Ubuntu 13.04 (my first Ubuntu release) booting in UEFI mode. So, I disabled secure boot and enabled the "Legacy CSM" and the system boots reliably from the hard drive. When I boot the Ubuntu 16.04 live DVD in non-UEFI mode, I never get a chance to specify the kernel parameters. When I boot the live DVD in UEFI mode, I get a chance to specify the kernel parameters.

Thanks!

Revision history for this message
Tomdkat (tomdkat) wrote :

I'll also attach the Xorg log from the system booted *without* "nomodeset" specified. I'll boot again with "set gfxpayload=text" specified and will post the logs.

Thanks!

Revision history for this message
Tomdkat (tomdkat) wrote :

Ok, this time, I have the live DVD booted with gfxpayload=text, "quiet splash" not specified, and "nomodeset" *not* specified. Once the optical drive stopped making noise, I pressed Ctrl-ALt-F1 and my monitor immediately got a signal. I then pressed Ctrl-Alt-F7 and got to the desktop.

I'll attach the dmesg and Xorg logs now.

Thanks!

Revision history for this message
Tomdkat (tomdkat) wrote :
Revision history for this message
penalvch (penalvch) wrote :

Tomdkat, I want to make sure you understand what you just said:
>"Well, if I'm not getting any video I'm not sure how I could get SSH setup..."

What is obvious is since you have a WORKAROUND, you engage it, setup SSH, reboot without the WORKAROUND, and then capture the logs. I'm not sure where the disconnect was on that.

Despite this, in order to allow additional upstream developers to examine the issue, at your earliest convenience, could you please test the latest upstream kernel available from http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D ? Please keep in mind the following:
1) The one to test is at the very top line at the top of the page (not the daily folder).
2) The release names are irrelevant.
3) The folder time stamps aren't indicative of when the kernel actually was released upstream.
4) Install instructions are available at https://wiki.ubuntu.com/Kernel/MainlineBuilds .

If testing on your main install would be inconvenient, one may:
1) Install Ubuntu to a different partition and then test this there.
2) Backup, or clone the primary install.

If the latest kernel did not allow you to test to the issue (ex. you couldn't boot into the OS) please make a comment in your report about this, and continue to test the next most recent kernel version until you can test to the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this issue is fixed in the mainline kernel, please add the following tags by clicking on the yellow circle with a black pencil icon, next to the word Tags, located at the bottom of the report description:
kernel-fixed-upstream
kernel-fixed-upstream-X.Y-rcZ

Where X, and Y are the first two numbers of the kernel version, and Z is the release candidate number if it exists.

If the mainline kernel does not fix the issue, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-X.Y-rcZ

Please note, an error to install the kernel does not fit the criteria of kernel-bug-exists-upstream.

Also, you don't need to apport-collect further unless specifically requested to do so.

Once testing of the latest upstream kernel is complete, please mark this report Status Confirmed. Please let us know your results.

Thank you for your understanding.

Revision history for this message
Tomdkat (tomdkat) wrote :

Thanks for the reply. With regard to SSH, I have access to only one system, the system on which I'm booting the live DVD. Ubuntu 14.04.2 is installed on the system and works just fine. So, I would prefer *not* touching this installation. I wanted to try the 16.04 live DVD to see if there might be any upgrade issues, once Ubuntu 16.04.1 is available.

So, I'll see if I can get Ubuntu 16.04 installed on the current system, using a different hard drive. Once I'm able to do that, I'll install the upstream kernel and will conduct tests. I'll report back my findings once I'm able to do so.

Thanks!

Revision history for this message
Tomdkat (tomdkat) wrote :

Ok, I _finally_ have an update on this. I put another hard drive into the system, booted an Ubuntu 16.04.1 live DVD I burned today, and installed Ubuntu 16.04.1 on this test hard drive. When I booted the live DVD, the video issue occurred, so I re-booted and specified the "nomodeset" parameter. After doing that, I was able to get the system to boot and was able to successfully install Ubuntu 16.04.1. After the installation completed, the system booted *without* my having to specify the "nomodeset" parameter and the monitor was running at full resolution (1600x900 or something along those lines). So, I thought maybe the issue had been fixed with the 16.04.1 release of Ubuntu. I removed the test hard drive, reinstalled the primary hard drive, booted the system to Ubuntu 14.04.2, and performed an _upgrade_ to Ubuntu 16.04.1. After the upgrade completed, the video issue returned *sigh*. However, I'm now able to get SSH setup so I can collect the requested logs.

I'm confused as to why a fresh install of Ubuntu 16.04.1 works but the upgrade doesn't. From what I understand, the AMD video driver is in the kernel and I would think the 4.4 kernel would be the same, regardless of the system being installed fresh vs being upgraded.

As of right now, the primary hard drive has Ubuntu 16.04.1 installed, the video issue is present, and kernel version 4.4-31 (I believe) is running. Once I'm able to get SSH setup and get the logs transferred to another system, I'll attach them to this bug report.

Thanks!

Revision history for this message
Tomdkat (tomdkat) wrote :

Ok, I have another update. I managed to get SSH setup and was able to save some XOrg and dmesg logs. However, I think this bug report can be closed. Why? Because, I'm able to get full resolution video with the 4.4 kernel. This is what I've found: if I boot my Ubuntu 16.04.1 system normally, with "quiet splash" set in the GRUB default config file (/etc/default/grub), I'll eventually get full resolution video on terminal #7 *but* only after about 30 mins.

Here's the situation:

1) I boot the system normally
2) I get a black screen for 30 "wall clock" minutes
3) After 30 mins, if I press Ctrl-Alt-F7, I get the Ubuntu login screen
4) I login as normal and get the Unity desktop at full resolution

So, I'm not sure why it takes 30 minutes for things to work but this is the case. We don't reboot the system very often, so this might not be a huge deal even though we will want to get this fixed, at some point.

So, from the perspective of this being a kernel bug, I'm not sure this bug report is valid. How do we proceed?

Thanks!

Revision history for this message
penalvch (penalvch) wrote :

Tomdkat, this is your report, so it's your call.

As far as I can tell, waiting 30 minutes seems an awfully lot to wait, even if you are patient enough, and don't reboot often.

Hence, to pursue this further, you would want to perform the test requested in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1598935/comments/11 and it wouldn't hurt to update your BIOS following https://help.ubuntu.com/community/BIOSUpdate .

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

Changed in linux (Ubuntu):
status: Incomplete → Expired
Revision history for this message
Tomdkat (tomdkat) wrote :

I have great news! The system is now booting properly! No more 20 minute wait to login! I noticed it with the update to the 4.4.0-42 kernel. So, this issue might have been fixed with either that kernel update or the previous, 4.4.0-38 kernel update.

In any event, this is no longer an issue and this bug report can be closed out. I'll close it, if I can. :)

Thanks!

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

Other bug subscribers

Remote bug watches

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