Call Trace messages in syslog with 4.4.0-116 kernel

[Rod Smith]

In doing regression testing of the 4.4.0-116 kernel with the server certification tools, the miscellanea/call-trace-check test failed on one system. (Maybe more, too; this was the first system to finish the tests.) This test simply looks for the string "Call Trace" in /var/log/syslog, and there are 44 such call traces. The system being tested was an Intel NUC DC53427HYE. The complete test results are available here:

https://certification.canonical.com/hardware/201508-19150/submission/127493/

I'm attaching the syslog file to this bug report, along with other requested data....

$ cat /proc/version_signature
Ubuntu 4.4.0-116.140-generic 4.4.98
$ lsb_release -rd
Description: Ubuntu 16.04.3 LTS
Release: 16.04
---
AlsaVersion: Advanced Linux Sound Architecture Driver Version k4.4.0-116-generic.
AplayDevices: Error: [Errno 2] No such file or directory
ApportVersion: 2.20.1-0ubuntu2.15
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', '/dev/snd/hwC0D3', '/dev/snd/pcmC0D8p', '/dev/snd/pcmC0D7p', '/dev/snd/pcmC0D3p', '/dev/snd/controlC0', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
Card0.Amixer.info: Error: [Errno 2] No such file or directory
Card0.Amixer.values: Error: [Errno 2] No such file or directory
DistroRelease: Ubuntu 16.04
IwConfig: Error: [Errno 2] No such file or directory
Package: linux (not installed)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-116-generic root=UUID=8dc86bcc-d6d5-4f11-b76e-c0b218a705c7 ro
ProcVersionSignature: User Name 4.4.0-116.140-generic 4.4.98
RelatedPackageVersions:
 linux-restricted-modules-4.4.0-116-generic N/A
 linux-backports-modules-4.4.0-116-generic N/A
 linux-firmware 1.157.16
RfKill: Error: [Errno 2] No such file or directory
Tags: xenial uec-images
Uname: Linux 4.4.0-116-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm audio cdrom dialout dip floppy lxd netdev plugdev sudo video
_MarkForUpload: True
dmi.bios.date: 09/10/2015
dmi.bios.vendor: Intel Corp.
dmi.bios.version: RKPPT10H.86A.0043.2015.0910.1015
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: D53427RKE
dmi.board.vendor: Intel Corporation
dmi.board.version: G87971-403
dmi.chassis.type: 3
dmi.modalias: dmi:bvnIntelCorp.:bvrRKPPT10H.86A.0043.2015.0910.1015:bd09/10/2015:svn:pn:pvr:rvnIntelCorporation:rnD53427RKE:rvrG87971-403:cvn:ct3:cvr:

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1749818

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Rod Smith (rodsmith)]

apport information

[Rod Smith (rodsmith)]

apport information

[Rod Smith (rodsmith)]

apport information

[Rod Smith (rodsmith)]

apport information

[Rod Smith (rodsmith)]

apport information

[Rod Smith (rodsmith)]

apport information

[Rod Smith (rodsmith)]

apport information

[Rod Smith (rodsmith)]

apport information

[Rod Smith (rodsmith)]

apport information

[Rod Smith (rodsmith)]

apport information

[Rod Smith (rodsmith)]

apport information

[Rod Smith (rodsmith)]

apport information

[Rod Smith (rodsmith)]

apport information

[Rod Smith (rodsmith)]

apport information

[Rod Smith (rodsmith)]

From Jeff Lane via e-mail:

> Hi. I can’t see the details right now because I’m on my phone and away from my desk. That said,
> that check is very basic, it fails on any call traces.
>
> Stress-ng might trigger some call traces if it triggers the OOM Killer which is fine, and
> should be expected during the memory tests. More troubling would be kernel panics.
>
> That check is VERY new and fairly trigger happy. It will definitely need some refinement.
>
> Point is, take it with a grain of salt and expect a lot of false positives from that check
> for now.

Most of the call traces are indeed on stress-ng, so this may not be a problem at all. It might be best if somebody from the kernel team can check the results just to be sure, though.

[Rod Smith (rodsmith)]

Every other system I've run through this round has shown the same failure on this test. I suspect it's simply a very high false alarm rate, as Jeff suggests, so I'm closing this out as "invalid."