dmesg:
[ 0.158736] mtrr: your CPUs had inconsistent variable MTRR settings
[ 0.158737] mtrr: probably your BIOS does not setup all CPUs.
[ 0.158738] mtrr: corrected configuration.
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: linux-image-4.3.0-5-generic 4.3.0-5.16
ProcVersionSignature: Ubuntu 4.3.0-5.16-generic 4.3.3
Uname: Linux 4.3.0-5-generic x86_64
ApportVersion: 2.19.3-0ubuntu2
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC0: caravena 1771 F.... pulseaudio
CurrentDesktop: GNOME
Date: Tue Jan 5 17:00:42 2016
HibernationDevice: RESUME=UUID=360bd2d2-4f44-4311-86d6-4781ac81ee87
InstallationDate: Installed on 2015-07-26 (163 days ago)
InstallationMedia: Ubuntu-GNOME 15.10 "Wily Werewolf" - Alpha amd64 (20150723)
MachineType: SAMSUNG ELECTRONICS CO., LTD. 530U3C/530U4C
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.3.0-5-generic root=UUID=4f4435ca-b877-47a5-9065-3dd624c0514e ro rootflags=subvol=@ quiet splash vt.handoff=7
RelatedPackageVersions:
linux-restricted-modules-4.3.0-5-generic N/A
linux-backports-modules-4.3.0-5-generic N/A
linux-firmware 1.154
SourcePackage: linux
UdevLog: Error: [Errno 2] No existe el archivo o el directorio: '/var/log/udev'
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/15/2013
dmi.bios.vendor: Phoenix Technologies Ltd.
dmi.bios.version: P14AAJ
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: SAMSUNG_NP1234567890
dmi.board.vendor: SAMSUNG ELECTRONICS CO., LTD.
dmi.board.version: FAB1
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 9
dmi.chassis.vendor: SAMSUNG ELECTRONICS CO., LTD.
dmi.chassis.version: 0.1
dmi.modalias: dmi:bvnPhoenixTechnologiesLtd.:bvrP14AAJ:bd04/15/2013:svnSAMSUNGELECTRONICSCO.,LTD.:pn530U3C/530U4C:pvr0.1:rvnSAMSUNGELECTRONICSCO.,LTD.:rnSAMSUNG_NP1234567890:rvrFAB1:cvnSAMSUNGELECTRONICSCO.,LTD.:ct9:cvr0.1:
dmi.product.name: 530U3C/530U4C
dmi.product.version: 0.1
dmi.sys.vendor: SAMSUNG ELECTRONICS CO., LTD.
Did this issue start happening after an update/upgrade? Was there a kernel version where you were not having this particular problem? This will help determine if the problem you are seeing is the result of a regression, and when this regression was introduced. If this is a regression, we can perform a kernel bisect to identify the commit that introduced the problem.