Random hangs

[Serrie]

System hangs randomly. This mostly occurs anywhere between 15 minutes and a few hours after boot. Couldn't figure out the trigger. Happened while viewing YouTube, using Spotify switching to Eclipse etc. SSH still works, so I can get to the machine if the lockup occurs. That's how I submitted the bug. All screens freeze though, while audio keeps on working (like music from Spotify or sound from a YouTube video). The only thing that seems to keep working UI-wise is the mouse pointer.

Had memtest running for half an hour without problems.

The issue occurs multiple times a day. Issue doesn't seem to be triggered if I remove linux-image-4.2.0-35-generic and go back to linux-image-4.2.0-16-generic. Did use the linux-image-4.2.0-16-generic kernel for a few days without issues.

The kern.log contains some stacktraces with the method being 'schedule'. This is around the time the hang occurs.

See extra debug information for more info.

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: linux-image-4.2.0-35-generic 4.2.0-35.40
ProcVersionSignature: Ubuntu 4.2.0-35.40-generic 4.2.8-ckt5
Uname: Linux 4.2.0-35-generic x86_64
ApportVersion: 2.19.1-0ubuntu5
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: serrie 1815 F.... pulseaudio
 /dev/snd/pcmC0D0c: serrie 1815 F...m pulseaudio
 /dev/snd/controlC0: serrie 1815 F.... pulseaudio
Date: Mon Apr 25 13:56:48 2016
InstallationDate: Installed on 2016-04-12 (13 days ago)
InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021)
IwConfig:
 docker0 no wireless extensions.

 enp4s0 no wireless extensions.

 lo no wireless extensions.
MachineType: System manufacturer System Product Name
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.2.0-35-generic root=UUID=c15a8aa0-fb21-495c-bbc6-ea4f2018dc1f ro quiet splash vt.handoff=7
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.2.0-35-generic N/A
 linux-backports-modules-4.2.0-35-generic N/A
 linux-firmware 1.149.3
RfKill:

SourcePackage: linux
UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
UpgradeStatus: Upgraded to wily on 2016-04-22 (3 days ago)
dmi.bios.date: 01/27/2016
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 0505
dmi.board.asset.tag: Default string
dmi.board.name: B150M-A D3
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: Rev X.0x
dmi.chassis.asset.tag: Default string
dmi.chassis.type: 3
dmi.chassis.vendor: Default string
dmi.chassis.version: Default string
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr0505:bd01/27/2016:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnB150M-AD3:rvrRevX.0x:cvnDefaultstring:ct3:cvrDefaultstring:
dmi.product.name: System Product Name
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer

[Brad Figg (brad-figg)]

This change was made by a bot.

[penalvch (penalvch)]

Serrie, 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.

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.

[Serrie (serrie)]

Latest upstream kernel is running stable for 2 days straight. No hangs and the kernel log is way cleaner, even though there are some i915 errors present. Attached the new kern.log if needed.

[penalvch (penalvch)]

Serrie, the next step is to fully reverse commit bisect from kernel 4.2 to 4.6-rc6 in order to identify the last bad commit, followed immediately by the first good one. Once this good commit has been identified, it may be reviewed for backporting. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection#How_do_I_reverse_bisect_the_upstream_kernel.3F ?

Please note, finding adjacent kernel versions is not fully commit bisecting.

After the fix commit (not kernel version) has been identified, then please mark this report Status Confirmed.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[Serrie (serrie)]

Thanks Christopher. I've tried to do this. These are my findings and I am not sure what to do next as the results seem not what I expect.

As the issue seems to be triggered some time between 15 minutes and a few hours I used 1 workday of no issues as a good sign and to give that specific running version the needed okay. Because of this testing took some time.
- 4.6.0 -> OK
- 4.4.0 -> OK
- 4.3.0 -> OK
- 4.2.8-ckt8 -> GFX bugs.. UI works but only 1 display out of 3 and every thing is immense slow UI-wise.
  From animations to even typing. If I change to non-X the console speed seems okay.
  Printing lots of data in the console (like catting a log file) is slowish though.
- 4.2.8-ckt9 -> Same as 4.2.8-ckt8.
- 4.2.8-ckt7 -> Same as 4.2.8-ckt8.
- 4.2.8-ckt6 -> same as 4.2.8-ckt8.
- 4.2.8-ckt5 -> same as 4.2.8-ckt8. Ubuntu-4.2.0-35.40 seems to be based on this. Though I don't have the slowness UI-wise with the Ubuntu kernel?
- 4.2.8-ckt4 -> same as 4.2.8-ckt8.
- 4.2.8-ckt3 -> same as 4.2.8-ckt8.
- 4.2.6 -> same as 4.2.8-ckt8.

I didn't run the one-day-OK test on the kernels with GFX issues as it didn't allow me to get some real work done in the mean time.

The Ubuntu kernel doesn't seem to have the 'i915.preliminary_hw_support=1' boot parameter which is needed pre 4.3.x to support the new Intel Skylake (6th gen.) GPUs. The only thing I can think of is that one of the Ubuntu patches done to kernels enables this by default?

I retried the kernels with the GFX issues after I added the boot paramter:
- 4.2.8-ckt9 -> OK. Only 2 displays work (even though it does see the third display there is no signal).
  Some minor GFX issues (UI artifacts with some transitions). But stable otherwise.
- 4.2.8-ckt8 -> Same as 4.2.8-ckt9.
- 4.2.8-ckt6 -> Same as 4.2.8-ckt9.
- 4.2.8-ckt4 -> Same as 4.2.8-ckt9.
- 4.2.8-ckt3 -> Same as 4.2.8-ckt9.

So I cannot seem to get the same issues with the mainline kernel the Ubuntu kernel is based on. Am I missing something, as I also cannot fully use all my screens which is possible with the Ubuntu kernel.

Hope it's okay if I put it on Confirmed as I think you might need it to get a trigger to look at this bug.

[Tony Beaumont (a-j-beaumont)]

I have this same problem with the UI freezing up. It always occurs when I resize a window, although not every time I resize a window. The app running inside the window isn't always the same, it is more often a code editor or a web browser, or a zoom meeting. The result is that the UI freezes up completely, although audio continues running so if I am on a video call I can still talk to people, or if I am playing something with audio, I can continue to hear it. Something seems to be going on with the machine because after a few seconds the I hear the fan turning on.

I'm running an up to date 20.04.1 LTS and the kernel is 5.4.0-58-generic. GNOME version is 3.36.8, windowing X11 and it's a 64-bit install. My laptop is Hewlett-Packard HP ZBook 17 G2/2255, BIOS M70 Ver. 01.12 09/23/2015