Internal laptop display stops working in 4.4.0-57-generic

[Jason C. McDonald]

I have a Toshiba Satellite P745D w/ AMD graphics, and I'm running the open source Radeon driver. I can use the internal and/or an external VGA monitor just fine in 4.4.0.53-generic and prior. However, upon updating to 4.4.0-57-generic, the internal monitor shuts off after GRUB and will not display anything. Setting NOMODESET in GRUB does not resolve the issue - I had to reboot into 4.4.0-53 to see anything on the internal laptop monitor.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: linux-image-4.4.0-53-generic 4.4.0-53.74
ProcVersionSignature: Ubuntu 4.4.0-53.74-generic 4.4.30
Uname: Linux 4.4.0-53-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.4
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/pcmC1D0p: jason 3081 F...m pulseaudio
 /dev/snd/controlC1: jason 3081 F.... pulseaudio
 /dev/snd/controlC0: jason 3081 F.... pulseaudio
CurrentDesktop: Unity
Date: Fri Dec 23 09:30:44 2016
HibernationDevice: RESUME=UUID=6428aefe-2277-446d-9209-a012d120611b
MachineType: TOSHIBA Satellite P745D
ProcFB: 0 radeondrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-53-generic root=UUID=7e97fb33-4ee2-499c-a3c4-69f37f16c4f4 ro quiet splash
RelatedPackageVersions:
 linux-restricted-modules-4.4.0-53-generic N/A
 linux-backports-modules-4.4.0-53-generic N/A
 linux-firmware 1.157.6
SourcePackage: linux
UpgradeStatus: Upgraded to xenial on 2016-05-01 (236 days ago)
dmi.bios.date: 05/26/2011
dmi.bios.vendor: TOSHIBA
dmi.bios.version: 1.10
dmi.board.asset.tag: NULL
dmi.board.name: QOQAE
dmi.board.vendor: TOSHIBA
dmi.board.version: 1.00
dmi.chassis.asset.tag: *
dmi.chassis.type: 10
dmi.chassis.vendor: TOSHIBA
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnTOSHIBA:bvr1.10:bd05/26/2011:svnTOSHIBA:pnSatelliteP745D:pvrPSMR1U-004001:rvnTOSHIBA:rnQOQAE:rvr1.00:cvnTOSHIBA:ct10:cvrN/A:
dmi.product.name: Satellite P745D
dmi.product.version: PSMR1U-004001
dmi.sys.vendor: TOSHIBA

[Brad Figg (brad-figg)]

This change was made by a bot.

[penalvch (penalvch)]

Jason C. McDonald, thank you for reporting this and helping make Ubuntu better.

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.

It is most helpful that after testing of the latest upstream kernel is complete, you mark this report Status Confirmed.

Lastly, to keep this issue relevant to upstream, please continue to test the latest mainline kernel as it becomes available.

Thank you for your help.

[Jason C. McDonald (codemouse92)]

Tested with v4.10 RC2, the bug is still present.

[penalvch (penalvch)]

Jason C. McDonald, the next step is to fully commit bisect from kernel 4.4.0.53 to 4.4.0-57 in order to identify the last good kernel commit, followed immediately by the first bad one. This will allow for a more expedited analysis of the root cause of your issue. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection ?

Please note, finding adjacent kernel versions, or providing a commit from a kernel version bisect is not fully commit bisecting.

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

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

Thank you for your help.

[Jason C. McDonald (codemouse92)]

Just a heads up - yes, I'm working on the full commit bisect. Good news, I know it's between 4.4.0.53 and 4.4.0.54 (the glitch is present in that version) - bad news, before I could do the next step in the bisect, I accidentally switched my ABI (I have two compilers). Now it is complaining about the ABI change, so I'm going to have to start over more or less.

I'll keep you posted.

[Jason C. McDonald (codemouse92)]

For whatever reason, the bad kernel is *apparently* `[61968528acfba3cf3cbf4d32f0bfba6fa9e754db] UBUNTU: Start new release`, the first following 4.4.0.53's release.

It may well be, although I also wonder if something went wrong with the commit bisect/build? (Feedback on that please).

To git bisect the kernel, I followed [these instructions](https://wiki.ubuntu.com/Kernel/KernelBisection#Commit_bisecting_Ubuntu_kernel_versions). building each version with...

```
vim debian.master changelog # Here, I made changes according to instructions
fakeroot debian/rules clean
fakeroot debian/rules binary-headers binary-generic binary-perarch
```

After each (1.5-2 hour) build, I install:

* `linux-headers-4.4.0-{whatever}_all.deb`
* `linux-headers-4.4.0-{whatever}-generic_{whatever}_amd64.deb`
* `linux-image-4.4.0-{whatever}--generic_{whatever}_amd64.deb`

Then I reboot into that kernel, and I invariably get:

* Nothing on the laptop screen (only on the external).
* Odd resolution (unlike 4.4.0-57 release and onward).
* No external mouse (unlike 4.4.0-57 release and onward).

Of course, the last two could be related to bisect landing in the middle, before the fixes for the two above, but I still wonder.

Finally, I reboot back into the working kernel, uninstall the three packages I just installed, and run `git bisect bad` (since the test kernel still doesn't work). Then I go back to tweaking the changelog and rebuilding.

[Jason C. McDonald (codemouse92)]

For the record, I also confirmed this bug on a fresh installation of Linux Mint 18.