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

[Bib]

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 3.13.11.4
Uname: Linux 3.13.0-32-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /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)
IwConfig:
 eth1 no wireless extensions.

 lo no wireless extensions.
MachineType: MSI MS-7721
ProcFB:

ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-32-generic root=UUID=09ecdff0-44fe-437e-8063-deabc6feb00e ro recovery nomodeset
RelatedPackageVersions:
 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
RfKill:

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)]

May be a duplicate of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1309578

[Brad Figg (brad-figg)]

This change was made by a bot.

[penalvch (penalvch)]

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:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

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

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:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

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.

[penalvch (penalvch)]

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 ?

[Bib (bybeu)]

KO:
Ubuntu 3.13.0-32.57-generic 3.13.11.4 (initial post)
3.13.0-24.47
3.13.0-34.60
3.13.0-35.62
linux-image-3.13.11-03131106-generic_3.13.11-03131106.201408131735_amd64

OK:
3.16.0-031600-generic

[Bib (bybeu)]

KO:
linux-image-3.15.0-031500-generic_3.15.0-031500.201406131105_amd64

[Bib (bybeu)]

KO:
linux-image-3.15.10-031510-generic_3.15.10-031510.201408132333_amd64 (last available 3.15)
OK:
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?

[penalvch (penalvch)]

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

[Bib (bybeu)]

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

[Matt (mdinger-bugzilla)]

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:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-3.16.y&id=0c78a44964db3d483b0c09a8236e0fe123aa9cfc

The follow up enables `bapm` only on MSI systems because he states other systems have stability issues when `bapm` is enabled:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-3.16.y&id=730a336c33a3398d65896e8ee3ef9f5679fe30a9

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)]

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?

[Bib (bybeu)]

Is it that? : https://wiki.ubuntu.com/Kernel/KernelBisection#How_do_I_bisect_the_upstream_kernel.3F

[Matt (mdinger-bugzilla)]

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:

https://wiki.ubuntu.com/Kernel/KernelBisection#Reverse_commit_bisecting_upstream_kernel_versions

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

So:
`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)]

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

[Matt (mdinger-bugzilla)]

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)]

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)]

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.

Christopher:
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)]

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

[Matt (mdinger-bugzilla)]

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.

https://wiki.ubuntu.com/Bugs/Bug%20importances

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)]

+1
Thx Matt

[NothingMuchHereToSay (nothingmuchhere-deactivatedaccount)]

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.

[penalvch (penalvch)]

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)]

NothingMuchHereToSay:

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)]

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:
https://wiki.ubuntu.com/Kernel/LTSEnablementStack#Kernel.2BAC8-Support.A14.04.x_Ubuntu_Kernel_Support

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

[Bib (bybeu)]

sudo dmidecode -s bios-version
V30.4

Issue remains in 3.13, still OK in 3.16

[Bib (bybeu)]

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.
     *-firmware
          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 3.13.0.36 to 39 with BIOS 30.4

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

[Matt (mdinger-bugzilla)]

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)]

Matt
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)]

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

[Bib (bybeu)]

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