[MSI A88XM-E35] Ubuntu 14.04.1 constant reboot without nomodeset

Bug #1355044 reported by Bib on 2014-08-11
This bug affects 6 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)

Bug Description

I needed to add nomodeset for initial install to prevent constant reboot from live usb. When done and trying to remove the nomodeset option out of /etc/default/grub, the constant reboot comes back, so I had to start in recovery to add nomodeset again.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: linux-image-3.13.0-32-generic 3.13.0-32.57
ProcVersionSignature: Ubuntu 3.13.0-32.57-generic
Uname: Linux 3.13.0-32-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
 /dev/snd/controlC1: fab 3896 F.... pulseaudio
 /dev/snd/controlC0: fab 3896 F.... pulseaudio
CurrentDesktop: Unity
Date: Mon Aug 11 09:41:49 2014
HibernationDevice: RESUME=UUID=66392631-7c4f-4773-8614-4c5ea0913890
InstallationDate: Installed on 2014-07-26 (16 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
 eth1 no wireless extensions.

 lo no wireless extensions.
MachineType: MSI MS-7721

ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-32-generic root=UUID=09ecdff0-44fe-437e-8063-deabc6feb00e ro recovery nomodeset
 linux-restricted-modules-3.13.0-32-generic N/A
 linux-backports-modules-3.13.0-32-generic N/A
 linux-firmware 1.127.5

SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 03/14/2014
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: V30.3
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: A88XM-E35 (MS-7721)
dmi.board.vendor: MSI
dmi.board.version: 6.0
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: MSI
dmi.chassis.version: 6.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrV30.3:bd03/14/2014:svnMSI:pnMS-7721:pvr6.0:rvnMSI:rnA88XM-E35(MS-7721):rvr6.0:cvnMSI:ct3:cvr6.0:
dmi.product.name: MS-7721
dmi.product.version: 6.0
dmi.sys.vendor: MSI

Bib (bybeu) wrote :

This change was made by a bot.

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

Bib, thank you for reporting this and helping make Ubuntu better. Could you please test the latest upstream kernel available from the very top line at the top of the page (not the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:

where VERSION-NUMBER is the version number of the kernel you tested exactly shown as:

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description.

If the mainline kernel does not fix this bug, please add the following tags:

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

tags: added: latest-bios-30.3
Changed in linux (Ubuntu):
importance: Undecided → Low
status: Confirmed → Incomplete
Bib (bybeu) on 2014-08-13
tags: added: kernel-fixed-upstream kernel-fixed-upstream-3.16.0-031600-generic
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
tags: added: kernel-fixed-upstream-3.16
removed: kernel-fixed-upstream-3.16.0-031600-generic
tags: added: needs-reverse-bisect

Bib, the next step is to fully reverse commit bisect the kernel in order to identify the fix commit. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection#How_do_I_reverse_bisect_the_upstream_kernel.3F ?

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
summary: - a88xm-e35 ubuntu 14.04.1 constant reboot without nomodeset
+ [MSI A88XM-E35] Ubuntu 14.04.1 constant reboot without nomodeset
Bib (bybeu) wrote :

Ubuntu 3.13.0-32.57-generic (initial post)


Bib (bybeu) wrote :


Bib (bybeu) wrote :

linux-image-3.15.10-031510-generic_3.15.10-031510.201408132333_amd64 (last available 3.15)
3.16.0-031600-generic (first non-rc 3.16)

Please Christopher, tell me if I also need to bissect 3.16-rc. Not dangerous?

Bib, you want to continue until the fix commit number is identified.

Bib (bybeu) wrote :

linux-image-3.16.0-031600rc3-generic_3.16.0-031600rc3.201406291835_amd64 (last guilty non-working)
linux-image-3.16.0-031600rc4-generic_3.16.0-031600rc4.201407061635_amd64 (first working)

Matt (mdinger-bugzilla) wrote :

Changelog for that lists these:

drm/radeon: only apply bapm changes for AC power on ARUBA
drm/radeon: enable bapm by default on KV/KB
drm/radeon: enable bapm by default on desktop TN/RL boards

Only the last one seems to be the only one to apply to Trinity APUs. The diff is here and it is the likely fix, however it shouldn't just be applied because it may cause stability issues with other non-MSI computers:

The follow up enables `bapm` only on MSI systems because he states other systems have stability issues when `bapm` is enabled:

If you have to bisect completely, this might let you only test 2 commits. Hopefully, the commit before my first link will fail and the first link's commit will work properly. Then the proper fix would be to apply both patches.

Bib (bybeu) wrote :

Thank you Matt.
I don't know how to "bisect completely". More, referring to https://wiki.ubuntu.com/Kernel/KernelBisection#How_do_I_reverse_bisect_the_upstream_kernel.3F that leads to (redirected) http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html, I can't find anything about 3.16 at http://people.canonical.com/~kernel/info/kernel-version-map.html to map ubuntu kernel to mainline one.
Is there a guide like the one I reach to follow up to now, to do the further more narrow bisect you advise?

Matt (mdinger-bugzilla) wrote :

Currently, the mapping from upstream to ubuntu doesn't seem to matter because christopher sent you to check upstream. Once he sees what the fix is, he can determine where it maps to the ubuntu kernel, if it actually does. This is probably the link you want:


Basically you clone the linux repository, make sure you can build the kernel (which takes a long time), and then you can start bisecting. The bisect command has you mark a `good` and a `bad` commit. It will proceed to check out the minimum number of commits so you can examine each to see where the bug started. Note: you don't need to use bisect. It's just a convenience tool.

Without bisect, follow these steps until you know which commit produced the bug:
1. Note a good and bad commit number
2. Checkout the commit half-way between the good and bad commit
3. Compile the source
4. Install the kernel
5. Test the kernel
6. If bad, mark as bad. If good, mark as good.
7. Go back to step 2

`git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git` to clone the repository
configure and build the kernel to make sure it builds
`git checkout 09f95d5` to checkout the last broken commit which is hopefully this one
`make clean` and build and test the kernel (hopefully the kernel doesn't work)
`git checkout 0c78a44` to checkout the first working commit
build and test the kernel

You can use something like gitg (https://wiki.gnome.org/Apps/Gitg) to visualize the git history. It may help.

If the second commit doesn't fix it...bisecting will take much longer. But that should be the fix.

Matt (mdinger-bugzilla) wrote :

Note: I'm skipping the steps which look to find the broken kernel and trying to jump right to the source.

Matt (mdinger-bugzilla) wrote :

Oops. Those checkouts will probably give you "detached head". Better to do this which will create a new branch when checking out:
`git checkout -b bad_radeon 09f95d5`
`git checkout -b good_radeon 0c78a44`

You can return to master branch with:
`git checkout master`

Bib (bybeu) wrote :

Matt, I just finished the test:
Both built in a running system linux-image-3.16.0-031600-generic (201408031935)
09f95d5 KO (3.16.0-rc2-custom #1
0c78a44 OK 3.16.0-rc2-custom #2 SMP Fri Sep 12 18:13:58 CEST 2014

uname -rv
3.16.0-rc2-custom #2 SMP Fri Sep 12 18:13:58 CEST 2014

Is it normal the builds are rc2 when previous tests show the issue ended between rc3 and rc4 ?

Matt (mdinger-bugzilla) wrote :

Nice! This looks like a good result.

I wouldn't be too concerned about the `rc2` in the string name. The hashes are exact and place the fix precisely and that is what is needed. `rc2` may just be because of how they manage the git tree.

The bisection is complete. What is the next step?

In order to apply 2 commits to the Ubuntu tree, is it necessary to test both of them? See comment 16 for more details.

Bib (bybeu) wrote :

Thank you very much Matt for this efficient guidance.
Now I think it is up to Christopher to speak.

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Matt (mdinger-bugzilla) wrote :

This bug should be high priority. From this page, it meets all but one of the criteria. Technically, there is a workaround but it isn't really simple. Possibly it is "Critical" importance because it renders the GPU unstable. Either way, this is not a low priority bug.


From the link, it meets all of these:

High: A bug which fulfills one of the following criteria:
- Has a severe impact on a small portion of Ubuntu users (estimated)
- Makes a default Ubuntu installation generally unusable for some users
  * For example, if the system fails to boot, or X fails to start, on a certain make and model of computer
 - A problem with an essential hardware component (disk controller, built-in networking, video card, keyboard, mouse)
 - Prevents the application or any dependencies from functioning correctly at all
 - Renders essential features or functionality of the application or dependencies broken or ineffective
 - Impacts accessibility of a core application

Bib (bybeu) wrote :

Thx Matt

tags: added: cherry-pick
removed: needs-reverse-bisect
tags: added: reverse-bisect-done
Changed in linux (Ubuntu):
status: Confirmed → Triaged

Hi, is this a continuation from the bug report from freedesktop.org?

I'd like to add that from the freedesktop bug report that someone had a Gigabyte motherboard and when bapm was enabled, the reporter experienced problems, but it fixed the constant rebooting problem on my MSI motherboard that has a Richland APU.

NothingMuchHereToSay, a fix commit has already been identified for this bug report.

If you want to help on this bug report, instead of providing speculation on what this is or isn't a continuation of, or WORKAROUNDs, file a new report via a terminal:
ubuntu-bug linux

and post in this new report if the commit noted as a fix for this bug addresses your issue.

Matt (mdinger-bugzilla) wrote :


Your comment seems accurate. The original fix was modified again to only enable bapm on MSI after stability issues were reported. See comment 16 and the 2nd link for more details (it's in the comments of the diff).

Matt (mdinger-bugzilla) wrote :

I'm not really familiar with the ubuntu kernel policy but it appears this bug will be irrelevant with 14.04.2 because it will contain kernel 3.16. This appears to be the new kernel policy:
- New ubuntu release gets a new kernel (14.10 for example)
- Wait a few months and push that new kernel to LTS

See here for more details:

So, they may just stall until next kernel upgrade and leave this as it is.

Bib (bybeu) wrote :

sudo dmidecode -s bios-version

Issue remains in 3.13, still OK in 3.16

tags: added: latest-bios-30.4
removed: latest-bios-30.3
Bib (bybeu) wrote :

uname -a
Linux nux 3.13.0-39-generic #66-Ubuntu
sudo lshw -C "" |grep -C6 "*-firmware"
       product: A88XM-E35 (MS-7721)
       mfg: MSI
       hw id: 0
       version: 6.0
       s/n: To be filled by O.E.M.
       loc: To be filled by O.E.M.
          description: BIOS
          mfg: American Megatrends Inc.
          identifiant matériel: 0
          version: V30.5
          date: 10/20/2014

OK :) thank you guys

I didn't try to 39 with BIOS 30.4

Christopher, I let you manage the tags (not sure what to do)

tags: added: latest-bios-30.5
removed: latest-bios-30.4
Matt (mdinger-bugzilla) wrote :

Ubuntu 14.04.2 has been released with kernel 3.16: https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#Updated_Packages

I assume that if you tested on 14.04.2, it would work properly and so this bug will be marked as fixed or wfm or whatever launchpad uses for this case.

@Bib: It may require reinstalling the new version to be positive though I'm not sure what the policy is.

Bib (bybeu) wrote :

As my 14.04.1 system works now, I'd rather not install the HWE Stack: I just had a very bad experience on 12.04 where HWE removed the nvidia-96 critical-for-me package that is no longer available in 12.04.5.
I'm not that much an adventurer.

Matt (mdinger-bugzilla) wrote :

That's fine. At least if someone reads the bug, they will see this bug is probably fixed.

Bib (bybeu) wrote :

At least 2 years after, I'm afraid no : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1705299

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

Other bug subscribers