[Kernel-packages] [Bug 1761379] Re: [18.04/18.10] File libperf-jvmti.so is missing in linux-tools-common deb on Ubuntu
Thanks Brad, I just saw that this has been in -proposed for a bit on bionic, missed that originally when looking for the file https://packages.ubuntu.com/search?searchon=contents&keywords=libperf-jvmti.so&mode=exactfilename&suite=bionic-updates&arch=any We'll keep our eyes peeled for the release. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-aws in Ubuntu. https://bugs.launchpad.net/bugs/1761379 Title: [18.04/18.10] File libperf-jvmti.so is missing in linux-tools-common deb on Ubuntu Status in The Ubuntu-power-systems project: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux-aws package in Ubuntu: New Status in linux source package in Artful: Won't Fix Status in linux-aws source package in Artful: New Status in linux source package in Bionic: Fix Released Status in linux-aws source package in Bionic: New Status in linux source package in Cosmic: Invalid Status in linux-aws source package in Cosmic: New Status in linux source package in Disco: Fix Released Status in linux-aws source package in Disco: New Bug description: [Impact] File libperf-jvmti.so is missing in linux-tools-common deb making it impossible to use perf for the JVM JITed methods. [Test case] $ sudo perf record -k 1 -e instructions:u ./java -agentpath:/usr/lib/linux-tools-5.0.0-8/libperf-jvmti.so crc32 $ sudo perf inject -i ./perf.data -j -o ./perf.data.jitted $ sudo perf report -f -i ./perf.data.jitted [Fix] Include java build dependencies and install the library into linux-tools package. [Regression potential] Small regression potential, an extra file is distributed and is not automatically linked to anything. It could impact the build, which was tested. ---Problem Description--- File libperf-jvmti.so is missing in linux-tools-common deb making it impossible to use perf for the JVM JITed methods ---uname output--- linux-image-4.13.0-36-generic Machine Type = not relevant ---Debugger--- A debugger is not configured ---Steps to Reproduce--- File libperf-jvmti.so is missing in linux-tools-common deb provided for Ubuntu 17.10 making it impossible to use perf for the JVM JITed methods. I also checked if the file is available on launchpad (https://launchpad.net/ubuntu/+source/linux) for Bionic Beaver proposed (main) at it's also absent there: gromero@ltc-wspoon3:~/download$ dpkg -c linux-tools-common_4.15.0-13.14_all.deb | fgrep jvm gromero@ltc-wspoon3:~/download$ dpkg -c linux-tools-4.15.0-13-generic_4.15.0-13.14_ppc64el.deb | fgrep jvm I do see the file in tools/perf/jvmti dir in the source .tar.gz, but apparently it's no being packaged in any .deb file? Thanks. Userspace tool common name: perf The userspace tool has the following bit modes: 64-bit Userspace tool obtained from project website: na To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1761379/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1761379] Re: [18.04/18.10] File libperf-jvmti.so is missing in linux-tools-common deb on Ubuntu
** Also affects: linux-aws (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-aws in Ubuntu. https://bugs.launchpad.net/bugs/1761379 Title: [18.04/18.10] File libperf-jvmti.so is missing in linux-tools-common deb on Ubuntu Status in The Ubuntu-power-systems project: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux-aws package in Ubuntu: New Status in linux source package in Artful: Won't Fix Status in linux-aws source package in Artful: New Status in linux source package in Bionic: Fix Released Status in linux-aws source package in Bionic: New Status in linux source package in Cosmic: Invalid Status in linux-aws source package in Cosmic: New Status in linux source package in Disco: Fix Released Status in linux-aws source package in Disco: New Bug description: [Impact] File libperf-jvmti.so is missing in linux-tools-common deb making it impossible to use perf for the JVM JITed methods. [Test case] $ sudo perf record -k 1 -e instructions:u ./java -agentpath:/usr/lib/linux-tools-5.0.0-8/libperf-jvmti.so crc32 $ sudo perf inject -i ./perf.data -j -o ./perf.data.jitted $ sudo perf report -f -i ./perf.data.jitted [Fix] Include java build dependencies and install the library into linux-tools package. [Regression potential] Small regression potential, an extra file is distributed and is not automatically linked to anything. It could impact the build, which was tested. ---Problem Description--- File libperf-jvmti.so is missing in linux-tools-common deb making it impossible to use perf for the JVM JITed methods ---uname output--- linux-image-4.13.0-36-generic Machine Type = not relevant ---Debugger--- A debugger is not configured ---Steps to Reproduce--- File libperf-jvmti.so is missing in linux-tools-common deb provided for Ubuntu 17.10 making it impossible to use perf for the JVM JITed methods. I also checked if the file is available on launchpad (https://launchpad.net/ubuntu/+source/linux) for Bionic Beaver proposed (main) at it's also absent there: gromero@ltc-wspoon3:~/download$ dpkg -c linux-tools-common_4.15.0-13.14_all.deb | fgrep jvm gromero@ltc-wspoon3:~/download$ dpkg -c linux-tools-4.15.0-13-generic_4.15.0-13.14_ppc64el.deb | fgrep jvm I do see the file in tools/perf/jvmti dir in the source .tar.gz, but apparently it's no being packaged in any .deb file? Thanks. Userspace tool common name: perf The userspace tool has the following bit modes: 64-bit Userspace tool obtained from project website: na To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1761379/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1761379] Re: [18.04/18.10] File libperf-jvmti.so is missing in linux-tools-common deb on Ubuntu
Can anyone comment as to whether or not this will be considered for kernels beyond -generic and -hwe? Specifically for aws, aws-hwe, and aws-edge kernels? -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1761379 Title: [18.04/18.10] File libperf-jvmti.so is missing in linux-tools-common deb on Ubuntu Status in The Ubuntu-power-systems project: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Artful: Won't Fix Status in linux source package in Bionic: Fix Released Status in linux source package in Cosmic: Invalid Status in linux source package in Disco: Fix Released Bug description: [Impact] File libperf-jvmti.so is missing in linux-tools-common deb making it impossible to use perf for the JVM JITed methods. [Test case] $ sudo perf record -k 1 -e instructions:u ./java -agentpath:/usr/lib/linux-tools-5.0.0-8/libperf-jvmti.so crc32 $ sudo perf inject -i ./perf.data -j -o ./perf.data.jitted $ sudo perf report -f -i ./perf.data.jitted [Fix] Include java build dependencies and install the library into linux-tools package. [Regression potential] Small regression potential, an extra file is distributed and is not automatically linked to anything. It could impact the build, which was tested. ---Problem Description--- File libperf-jvmti.so is missing in linux-tools-common deb making it impossible to use perf for the JVM JITed methods ---uname output--- linux-image-4.13.0-36-generic Machine Type = not relevant ---Debugger--- A debugger is not configured ---Steps to Reproduce--- File libperf-jvmti.so is missing in linux-tools-common deb provided for Ubuntu 17.10 making it impossible to use perf for the JVM JITed methods. I also checked if the file is available on launchpad (https://launchpad.net/ubuntu/+source/linux) for Bionic Beaver proposed (main) at it's also absent there: gromero@ltc-wspoon3:~/download$ dpkg -c linux-tools-common_4.15.0-13.14_all.deb | fgrep jvm gromero@ltc-wspoon3:~/download$ dpkg -c linux-tools-4.15.0-13-generic_4.15.0-13.14_ppc64el.deb | fgrep jvm I do see the file in tools/perf/jvmti dir in the source .tar.gz, but apparently it's no being packaged in any .deb file? Thanks. Userspace tool common name: perf The userspace tool has the following bit modes: 64-bit Userspace tool obtained from project website: na To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1761379/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1803600] Re: Elantech - Touchpad not working after upgrading to 18.10 from 18.04
I'm using a Thinkpad T480s and while my Elantech touchpad was mostly functional upon moving to 18.10 two-finger right-click and three-finger middle-click stopped working. `libinput list-devices` showed 'none' for a couple of features like 'Click methods.' The same fixes above worked for me (both the kernel command line as well as the sysfs protocol tweak). Currently running 4.18.0-15-generic # cat /sys/bus/serio/devices/serio1/firmware_id PNP: LEN008f PNP0f13 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1803600 Title: Elantech - Touchpad not working after upgrading to 18.10 from 18.04 Status in linux package in Ubuntu: Confirmed Bug description: Confirmed affected laptops: ThinkPad: L480 L580 P72 P52 When updating from 18.04 to 18.10 on a ThinkPad L480 the Elantech touchpad stopped working. This means it is not recognized at all. This problem occured after the first boot in 18.10 `dmesg | grep -i elantech` shows the following errors: [3.409043] psmouse serio1: elantech: assuming hardware version 4 (with firmware version 0x5f3001) [3.427372] psmouse serio1: elantech: Synaptics capabilities query result 0x90, 0x18, 0x10. [3.447275] psmouse serio1: elantech: Elan sample query result 00, 23, c8 [3.464905] psmouse serio1: elantech: Trying to set up SMBus access [5.576149] elan_i2c 0-0015: 0-0015 supply vcc not found, using dummy regulator [5.586505] elan_i2c 0-0015: failed to get resolution: -71 [5.586527] elan_i2c: probe of 0-0015 failed with error -71 uname: $ uname -a Linux test 4.18.0-10-generic #11-Ubuntu SMP Thu Oct 11 15:13:55 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux I found the following thread which solves the problem temporarly (and reports the same problem in Arch): https://bugs.archlinux.org/task/59714 Running the following command enables it again for the current session: sudo sh -c 'echo -n "elantech"> /sys/bus/serio/devices/serio1/protocol' dmesg afterwards: [ 569.522490] psmouse serio1: elantech: assuming hardware version 4 (with firmware version 0x5f3001) [ 569.544584] psmouse serio1: elantech: Synaptics capabilities query result 0x90, 0x18, 0x10. [ 569.565939] psmouse serio1: elantech: Elan sample query result 00, 23, c8 Before running the fix: $ cat /sys/bus/serio/devices/serio1/protocol ETSMBus and after: $ cat /sys/bus/serio/devices/serio1/protocol ETPS/2 After reboot the command has to be run again, of course. ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: xorg 1:7.7+19ubuntu8 ProcVersionSignature: Ubuntu 4.18.0-11.12-generic 4.18.12 Uname: Linux 4.18.0-11-generic x86_64 ApportVersion: 2.20.10-0ubuntu13.1 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None CurrentDesktop: KDE Date: Thu Nov 15 20:59:36 2018 DistUpgraded: 2018-11-10 09:56:53,358 DEBUG icon theme changed, re-reading DistroCodename: cosmic DistroVariant: ubuntu DkmsStatus: virtualbox, 5.2.18, 4.15.0-38-generic, x86_64: installed virtualbox, 5.2.18, 4.18.0-10-generic, x86_64: installed virtualbox, 5.2.18, 4.18.0-11-generic, x86_64: installed GraphicsCard: Intel Corporation UHD Graphics 620 [8086:5917] (rev 07) (prog-if 00 [VGA controller]) Subsystem: Lenovo UHD Graphics 620 [17aa:506a] InstallationDate: Installed on 2018-08-06 (101 days ago) InstallationMedia: Xubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) MachineType: LENOVO 20LS001AGE ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.18.0-11-generic root=UUID=a1f97298-a2b8-469d-80ed-7497c6e6 ro quiet splash vt.handoff=1 SourcePackage: xorg Symptom: display UpgradeStatus: Upgraded to cosmic on 2018-11-10 (5 days ago) dmi.bios.date: 02/09/2018 dmi.bios.vendor: LENOVO dmi.bios.version: R0QET37W (1.14 ) dmi.board.asset.tag: Not Available dmi.board.name: 20LS001AGE dmi.board.vendor: LENOVO dmi.board.version: SDK0J40697 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrR0QET37W(1.14):bd02/09/2018:svnLENOVO:pn20LS001AGE:pvrThinkPadL480:rvnLENOVO:rn20LS001AGE:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad L480 dmi.product.name: 20LS001AGE dmi.product.sku: LENOVO_MT_20LS_BU_Think_FM_ThinkPad L480 dmi.product.version: ThinkPad L480 dmi.sys.vendor: LENOVO version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.95-1 version.libgl1-mesa-dri: libgl1-mesa-dri 18.2.4-0~b~padoka0 version.libgl1-mesa-glx: libgl1-mesa-glx 18.2.4-0~b~padoka0 version.xserver-xorg-core: xserver-xorg
[Kernel-packages] [Bug 1788035] Re: nvme: avoid cqe corruption
We encountered an instance that had a nvme failure very early on in boot today. I've updated our internal Canonical case as well as our Amazon case on this, but posting relevant details here as well for consistency: # uname -a Linux XXX 4.4.0-1069-aws #79-Ubuntu SMP Mon Sep 24 15:01:41 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux # cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=16.04 DISTRIB_CODENAME=xenial DISTRIB_DESCRIPTION="Ubuntu 16.04.5 LTS" # echo type $EC2_INSTANCE_TYPE type m5.xlarge # lsblk NAMEMAJ:MIN RM SIZE RO TYPE MOUNTPOINT nvme0n1 259:00 10G 0 disk / # ls -al /dev/nvme* /dev/xvd* /dev/sd* ls: cannot access '/dev/xvd*': No such file or directory crw--- 1 root root 248, 0 Oct 31 15:02 /dev/nvme0 brw-rw 1 root disk 259, 0 Oct 31 15:02 /dev/nvme0n1 lrwxrwxrwx 1 root root 7 Oct 31 15:02 /dev/sda1 -> nvme0n1 # dmesg | grep '63\.' [ 63.401466] nvme :00:1f.0: I/O 0 QID 0 timeout, disable controller [ 63.505790] nvme :00:1f.0: Cancelling I/O 0 QID 0 [ 63.505812] nvme :00:1f.0: Identify Controller failed (-4) [ 63.507536] nvme :00:1f.0: Removing after probe failure [ 63.507604] iounmap: bad address c90001b4 [ 63.508941] CPU: 1 PID: 351 Comm: kworker/1:3 Tainted: P O 4.4.0-1069-aws #79-Ubuntu [ 63.508943] Hardware name: Amazon EC2 m5.xlarge/, BIOS 1.0 10/16/2017 [ 63.508948] Workqueue: events nvme_remove_dead_ctrl_work [nvme] [ 63.508950] 0286 3501e2639044a4d2 8800372bfce0 923ffe03 [ 63.508952] 88040dd878f0 c90001b4 8800372bfd00 9206d3af [ 63.508954] 88040dd878f0 88040dd87a58 8800372bfd10 9206d3ec [ 63.508956] Call Trace: [ 63.508961] [] dump_stack+0x63/0x90 [ 63.508965] [] iounmap.part.1+0x7f/0x90 [ 63.508967] [] iounmap+0x2c/0x30 [ 63.508969] [] nvme_dev_unmap.isra.35+0x1a/0x30 [nvme] [ 63.508972] [] nvme_remove+0xce/0xe0 [nvme] [ 63.508976] [] pci_device_remove+0x3e/0xc0 [ 63.508980] [] __device_release_driver+0xa4/0x150 [ 63.508982] [] device_release_driver+0x23/0x30 [ 63.508986] [] pci_stop_bus_device+0x7a/0xa0 [ 63.508988] [] pci_stop_and_remove_bus_device_locked+0x1a/0x30 [ 63.508990] [] nvme_remove_dead_ctrl_work+0x3c/0x50 [nvme] [ 63.508994] [] process_one_work+0x16b/0x490 [ 63.508996] [] worker_thread+0x4b/0x4d0 [ 63.508998] [] ? process_one_work+0x490/0x490 [ 63.509001] [] kthread+0xe7/0x100 [ 63.509005] [] ? __schedule+0x301/0x7f0 [ 63.509007] [] ? kthread_create_on_node+0x1e0/0x1e0 [ 63.509009] [] ret_from_fork+0x55/0x80 [ 63.509011] [] ? kthread_create_on_node+0x1e0/0x1e0 [ 63.509013] Trying to free nonexistent resource# modinfo nvme filename: /lib/modules/4.4.0-1069-aws/kernel/drivers/nvme/host/nvme.ko version:1.0 license:GPL author: Matthew Wilcox srcversion: 5CF522443B009A8675C497B alias: pci:v106Bd2001sv*sd*bc*sc*i* alias: pci:v*d*sv*sd*bc01sc08i02* alias: pci:v144DdA822sv*sd*bc*sc*i* alias: pci:v144DdA821sv*sd*bc*sc*i* alias: pci:v1C58d0003sv*sd*bc*sc*i* alias: pci:v8086d5845sv*sd*bc*sc*i* alias: pci:v8086dF1A5sv*sd*bc*sc*i* alias: pci:v8086d0953sv*sd*bc*sc*i* depends: retpoline: Y intree: Y vermagic: 4.4.0-1069-aws SMP mod_unload modversions retpoline parm: admin_timeout:timeout in seconds for admin commands (uint) parm: io_timeout:timeout in seconds for I/O (uint) parm: shutdown_timeout:timeout in seconds for controller shutdown (byte) parm: use_threaded_interrupts:int parm: use_cmb_sqes:use controller's memory buffer for I/O SQes (bool) parm: nvme_major:int parm: nvme_char_major:int parm: default_ps_max_latency_us:max power saving latency for new devices; use PM QOS to change per device (ulong) # systool -m nvme -va Module = "nvme" Attributes: coresize= "65536" initsize= "0" initstate = "live" refcnt = "1" srcversion = "5CF522443B009A8675C497B" taint = "" uevent = version = "1.0" Parameters: admin_timeout = "60" default_ps_max_latency_us= "10" io_timeout = "4294967295" shutdown_timeout= "5" use_cmb_sqes= "Y" Sections: .bss= "0xc03a3780" .data = "0xc03a3000" .data.unlikely = "0xc03a33d8" .exit.text = "0xc03a0cea" .gnu.linkonce.this_module= "0xc03a3400" .init.text = "0xc03a8000" .note.gnu.build-id = "0xc03a1000" .parainstructions = "0xc03a1b88" .rodata = "0xc03a1060" .rodata.str1.1 =
[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/tree/kernel/sysctl.c#n2433
and
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/tree/kernel/sysctl.c#n2446
are the source(s) of the noise
Looking at nearby functions like proc_dointvec_ibrs_ctrl and
proc_dointvec_ipbp_ctrl, I suspect the intention was to use pr_debug
instead of printk...
Introduced in this commit:
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/commit/kernel/sysctl.c?id=5e7fa0233bdfe2906216606d0d4d156be8f86950
I haven't done any digging on 3.13 but expect it will be similar.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627
Title:
ibrs/ibpb fixes result in excessive kernel logging
Status in linux package in Ubuntu:
Confirmed
Status in linux source package in Trusty:
Triaged
Status in linux source package in Xenial:
Triaged
Bug description:
Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
results in kernel logs similar to the following:
% sysctl -a &>/dev/null; dmesg -T | tail -8
[Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
The output varies with the number of CPUs.
After digging a bit, it turns out this is triggered upon every read of
`kernel.ibrs_dump`:
% for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo;
sleep 1; done
kernel.ibrs_dump = 0
[Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
kernel.ibrs_dump = 0
[Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
kernel.ibrs_dump = 0
[Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic
4.4.98 per /proc/version_signature
Normally this would not be the biggest concern but we have tooling
that gathers instance info on a schedule, including sysctl output,
thus resulting in the kernel ring buffer being full of nothing but
said output in most cases and hindering live troubleshooting as a
result.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging
Also, to call it out again, this appears to affect Trusty's LTS kernel,
too (it's not clear how one marks a bug as such from the Launchpad UI)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627
Title:
ibrs/ibpb fixes result in excessive kernel logging
Status in linux package in Ubuntu:
Confirmed
Status in linux source package in Xenial:
Confirmed
Bug description:
Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
results in kernel logs similar to the following:
% sysctl -a &>/dev/null; dmesg -T | tail -8
[Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
The output varies with the number of CPUs.
After digging a bit, it turns out this is triggered upon every read of
`kernel.ibrs_dump`:
% for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo;
sleep 1; done
kernel.ibrs_dump = 0
[Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
kernel.ibrs_dump = 0
[Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
kernel.ibrs_dump = 0
[Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic
4.4.98 per /proc/version_signature
Normally this would not be the biggest concern but we have tooling
that gathers instance info on a schedule, including sysctl output,
thus resulting in the kernel ring buffer being full of nothing but
said output in most cases and hindering live troubleshooting as a
result.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging
For the sake of completeness on this one, I installed the following
mainline packages on an AWS m5.large instance running 16.04.3 w/
4.4.0-112-generic
- linux-headers-4.16.0-041600rc4_4.16.0-041600rc4.201803041930_all.deb
- linux-headers-4.16.0-041600rc4-generic_4.16.0-041600rc4.201803041930_amd64.deb
- linux-image-4.16.0-041600rc4-generic_4.16.0-041600rc4.201803041930_amd64.deb
This does NOT trigger the bug, either via `sysctl -a` or `sysctl
kernel.ibrs_dump` as `/proc/sys/kernel/ibrs_dump` does not exist. This
is the same behavior on Bionic w/ 4.15.
** Tags added: kernel-fixed-upstream
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627
Title:
ibrs/ibpb fixes result in excessive kernel logging
Status in linux package in Ubuntu:
Confirmed
Status in linux source package in Xenial:
Confirmed
Bug description:
Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
results in kernel logs similar to the following:
% sysctl -a &>/dev/null; dmesg -T | tail -8
[Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
The output varies with the number of CPUs.
After digging a bit, it turns out this is triggered upon every read of
`kernel.ibrs_dump`:
% for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo;
sleep 1; done
kernel.ibrs_dump = 0
[Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
kernel.ibrs_dump = 0
[Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
kernel.ibrs_dump = 0
[Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic
4.4.98 per /proc/version_signature
Normally this would not be the biggest concern but we have tooling
that gathers instance info on a schedule, including sysctl output,
thus resulting in the kernel ring buffer being full of nothing but
said output in most cases and hindering live troubleshooting as a
result.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging
It's worth noting, too, that this does not happen on Bionic @ 4.15
(using Ubuntu 4.15.0-1001.1-aws 4.15.3) but it does happen on Trusty
(using Ubuntu 3.13.0-143.192-generic 3.13.11-ckt39)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627
Title:
ibrs/ibpb fixes result in excessive kernel logging
Status in linux package in Ubuntu:
Confirmed
Status in linux source package in Xenial:
Confirmed
Bug description:
Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
results in kernel logs similar to the following:
% sysctl -a &>/dev/null; dmesg -T | tail -8
[Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
The output varies with the number of CPUs.
After digging a bit, it turns out this is triggered upon every read of
`kernel.ibrs_dump`:
% for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo;
sleep 1; done
kernel.ibrs_dump = 0
[Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
kernel.ibrs_dump = 0
[Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
kernel.ibrs_dump = 0
[Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic
4.4.98 per /proc/version_signature
Normally this would not be the biggest concern but we have tooling
that gathers instance info on a schedule, including sysctl output,
thus resulting in the kernel ring buffer being full of nothing but
said output in most cases and hindering live troubleshooting as a
result.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging
We do not use apport and this is easily reproducible. If there is any
pointed information I can provide beyond what I've already submitted,
please let me know.
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627
Title:
ibrs/ibpb fixes result in excessive kernel logging
Status in linux package in Ubuntu:
Confirmed
Bug description:
Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
results in kernel logs similar to the following:
% sysctl -a &>/dev/null; dmesg -T | tail -8
[Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
The output varies with the number of CPUs.
After digging a bit, it turns out this is triggered upon every read of
`kernel.ibrs_dump`:
% for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo;
sleep 1; done
kernel.ibrs_dump = 0
[Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
kernel.ibrs_dump = 0
[Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
kernel.ibrs_dump = 0
[Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic
4.4.98 per /proc/version_signature
Normally this would not be the biggest concern but we have tooling
that gathers instance info on a schedule, including sysctl output,
thus resulting in the kernel ring buffer being full of nothing but
said output in most cases and hindering live troubleshooting as a
result.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1755627] [NEW] ibrs/ibpb fixes result in excessive kernel logging
Public bug reported:
Since at least kernel 4.4.0-116, every invocation of `sysctl -a` results
in kernel logs similar to the following:
% sysctl -a &>/dev/null; dmesg -T | tail -8
[Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
The output varies with the number of CPUs.
After digging a bit, it turns out this is triggered upon every read of
`kernel.ibrs_dump`:
% for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; sleep
1; done
kernel.ibrs_dump = 0
[Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
kernel.ibrs_dump = 0
[Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
kernel.ibrs_dump = 0
[Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic
4.4.98 per /proc/version_signature
Normally this would not be the biggest concern but we have tooling that
gathers instance info on a schedule, including sysctl output, thus
resulting in the kernel ring buffer being full of nothing but said
output in most cases and hindering live troubleshooting as a result.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: Incomplete
** Tags: xenial
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627
Title:
ibrs/ibpb fixes result in excessive kernel logging
Status in linux package in Ubuntu:
Incomplete
Bug description:
Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
results in kernel logs similar to the following:
% sysctl -a &>/dev/null; dmesg -T | tail -8
[Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
The output varies with the number of CPUs.
After digging a bit, it turns out this is triggered upon every read of
`kernel.ibrs_dump`:
% for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo;
sleep 1; done
kernel.ibrs_dump = 0
[Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
kernel.ibrs_dump = 0
[Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
kernel.ibrs_dump = 0
[Wed Mar 14 00:08:50 2018] sysc
[Kernel-packages] [Bug 1679768] Re: Docker build hangs on XFS with kernel 4.10
Seeing the same on Xenial when using linux-hwe-edge ** Also affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1679768 Title: Docker build hangs on XFS with kernel 4.10 Status in docker.io package in Ubuntu: Incomplete Status in linux package in Ubuntu: New Bug description: I have my docker partition on XFS, and recently upgraded to Zesty Beta. Most of my `docker build.` processes hangs with a similar message in syslog: ``` Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171267] INFO: task kworker/1:3:5589 blocked for more than 120 seconds. Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171275] Tainted: P O4.10.0-15-generic #17-Ubuntu Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171278] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171282] kworker/1:3 D0 5589 2 0x Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171310] Workqueue: aufsd wkq_func [aufs] Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171313] Call Trace: Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171323] __schedule+0x233/0x6f0 Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171415] ? kmem_zone_alloc+0x81/0x120 [xfs] Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171419] schedule+0x36/0x80 Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171423] rwsem_down_read_failed+0xfa/0x150 Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171491] ? xfs_file_buffered_aio_read+0x3d/0xc0 [xfs] Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171496] call_rwsem_down_read_failed+0x18/0x30 Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171500] down_read+0x20/0x40 Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171567] xfs_ilock+0xf5/0x110 [xfs] Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171628] xfs_file_buffered_aio_read+0x3d/0xc0 [xfs] Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171686] xfs_file_read_iter+0x68/0xc0 [xfs] Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171692] new_sync_read+0xd2/0x120 Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171695] __vfs_read+0x26/0x40 Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171697] vfs_read+0x96/0x130 Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171715] vfsub_read_u+0x14/0x30 [aufs] Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171729] vfsub_read_k+0x2c/0x40 [aufs] Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171743] au_copy_file+0x10c/0x370 [aufs] Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171756] au_cp_regular+0x11a/0x200 [aufs] Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171767] ? au_cp_regular+0x1ef/0x200 [aufs] Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171777] ? au_cp_regular+0x188/0x200 [aufs] Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171788] cpup_entry+0x538/0x5f0 [aufs] Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171802] ? vfsub_lookup_one_len+0x31/0x70 [aufs] Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171814] au_cpup_single.constprop.18+0x145/0x6a0 [aufs] Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171820] ? dput+0x40/0x270 Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171831] au_cpup_simple+0x4d/0x80 [aufs] Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171842] au_call_cpup_simple+0x28/0x40 [aufs] Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171855] wkq_func+0x14/0x80 [aufs] Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171861] process_one_work+0x1fc/0x4b0 Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171864] worker_thread+0x4b/0x500 Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171870] kthread+0x101/0x140 Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171873] ? process_one_work+0x4b0/0x4b0 Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171878] ? kthread_create_on_node+0x60/0x60 Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171883] ? SyS_exit_group+0x14/0x20 Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171887] ret_from_fork+0x2c/0x40 Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171895] INFO: task useradd:5758 blocked for more than 120 seconds. Apr 4 09:19:04 epuspdxn0004 kernel: [ 1330.171899] Tainted: P O4.10.0-15-generic #17-Ubuntu ``` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1679768/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1308796] Re: Bad page map in openjdk-7
@Viktor, I believe that patch was later reverted and a new one was issued to fix https://lkml.org/lkml/2014/4/10/174 https://lkml.org/lkml/2014/4/8/173 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1308796 Title: Bad page map in openjdk-7 Status in “linux” package in Ubuntu: Confirmed Bug description: [ 2808.161850] BUG: Bad page map in process java pte:0320 pmd:e8048067 [ 2808.161860] addr:7f968a63a000 vm_flags:0870 anon_vma: (null) mapping: (null) index:7f968a63a [ 2808.161866] CPU: 0 PID: 18543 Comm: java Tainted: GB 3.13.0-24-generic #46-Ubuntu [ 2808.161868] 8800e7f623c0 8800e8277a98 81715a64 7f968a63a000 [ 2808.161871] 8800e8277ae0 81174183 0320 0007f968a63a [ 2808.161872] 8800e80481d0 0320 7f968a63a000 7f968a63b000 [ 2808.161874] Call Trace: [ 2808.161881] [] dump_stack+0x45/0x56 [ 2808.161884] [] print_bad_pte+0x1a3/0x250 [ 2808.161886] [] vm_normal_page+0x69/0x80 [ 2808.161888] [] unmap_page_range+0x3bb/0x7f0 [ 2808.161890] [] unmap_single_vma+0x81/0xf0 [ 2808.161892] [] unmap_vmas+0x49/0x90 [ 2808.161894] [] exit_mmap+0x9c/0x170 [ 2808.161898] [] ? __delayacct_add_tsk+0x153/0x170 [ 2808.161901] [] mmput+0x5c/0x120 [ 2808.161903] [] do_exit+0x26c/0xa50 [ 2808.161906] [] ? __unqueue_futex+0x31/0x60 [ 2808.161907] [] ? futex_wait+0x126/0x290 [ 2808.161909] [] do_group_exit+0x3f/0xa0 [ 2808.161912] [] get_signal_to_deliver+0x1d0/0x6f0 [ 2808.161916] [] do_signal+0x48/0x960 [ 2808.161919] [] ? sched_clock+0x9/0x10 [ 2808.161921] [] ? sched_clock_local+0x1d/0x80 [ 2808.161924] [] ? acct_account_cputime+0x1c/0x20 [ 2808.161925] [] ? account_user_time+0x8b/0xa0 [ 2808.161927] [] ? vtime_account_user+0x54/0x60 [ 2808.161929] [] do_notify_resume+0x69/0xb0 [ 2808.161932] [] int_signal+0x12/0x17 ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: linux-image-3.13.0-24-generic 3.13.0-24.46 ProcVersionSignature: Ubuntu 3.13.0-24.46-generic 3.13.9 Uname: Linux 3.13.0-24-generic x86_64 AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Apr 16 22:18 seq crw-rw 1 root audio 116, 33 Apr 16 22:18 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.14.1-0ubuntu3 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: Error: [Errno 2] No such file or directory: 'iw' Date: Thu Apr 17 00:06:35 2014 Ec2AMI: ami-2ef19b1e Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-west-2a Ec2InstanceType: m3.medium Ec2Kernel: aki-fc8f11cc Ec2Ramdisk: unavailable IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' Lspci: Error: [Errno 2] No such file or directory: 'lspci' Lsusb: Error: [Errno 2] No such file or directory: 'lsusb' PciMultimedia: ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: ProcKernelCmdLine: root=UUID=ecdfe459-e35e-4416-a9c1-9ee71f9f93e7 ro RelatedPackageVersions: linux-restricted-modules-3.13.0-24-generic N/A linux-backports-modules-3.13.0-24-generic N/A linux-firmware N/A RfKill: Error: [Errno 2] No such file or directory: 'rfkill' SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) --- AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Apr 17 17:56 seq crw-rw 1 root audio 116, 33 Apr 17 17:56 timer AplayDevices: Error: [Errno 2] No such file or directory ApportVersion: 2.14.1-0ubuntu3 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: Error: [Errno 2] No such file or directory CurrentDmesg: Error: command ['sh', '-c', 'dmesg | comm -13 --nocheck-order /var/log/dmesg -'] failed with exit code 1: comm: /var/log/dmesg: Permission denied DistroRelease: Ubuntu 14.04 Ec2AMI: ami-2ef19b1e Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-west-2a Ec2InstanceType: m3.medium Ec2Kernel: aki-fc8f11cc Ec2Ramdisk: unavailable IwConfig: Error: [Errno 2] No such file or directory Lspci: Error: [Errno 2] No such file or directory Lsusb: Error: [Errno 2] No such file or directory Package: linux (not installed) PciMultimedia: ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/zsh ProcFB: ProcKernelCmdLine: root=UUID=ecdfe459-e35e-4416-a9c1-9ee71f9f93e7 ro ProcVersionSignature: Ubuntu 3.13.0-24.46-generic 3.13.9 RfKill: Error
