[Kernel-packages] [Bug 1958918] Re: dependency on crda obsolete according to Debian
@vorlon, I just found this ticket, and would like to report that my Intel AX211 wifi card no longer connects via 6ghz with the linux-oem-22.04b. It was working fine with the 5.15 kernel. I suspect regulatory compliance to be the issue as all of the 6ghz channels show disabled when running $ sudo iw phy0 channels. They also are unlisted when running $ sudo iw reg get I haven't figured out how to manually fix this yet. I have tried adding the missing iwlwifi-so-a0-gf-a0-72.ucode to /lib/firmware and it loads, but this did not fix the issue as I expected. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-lowlatency in Ubuntu. https://bugs.launchpad.net/bugs/1958918 Title: dependency on crda obsolete according to Debian Status in crda package in Ubuntu: New Status in linux package in Ubuntu: Fix Released Status in linux-aws package in Ubuntu: Fix Released Status in linux-azure package in Ubuntu: Fix Released Status in linux-gcp package in Ubuntu: Fix Released Status in linux-lowlatency package in Ubuntu: Fix Released Status in linux-oracle package in Ubuntu: Fix Released Status in linux-raspi package in Ubuntu: Fix Released Status in crda source package in Jammy: New Status in linux source package in Jammy: Fix Released Status in linux-aws source package in Jammy: Fix Released Status in linux-azure source package in Jammy: Fix Released Status in linux-gcp source package in Jammy: Fix Released Status in linux-lowlatency source package in Jammy: Fix Released Status in linux-oracle source package in Jammy: Fix Released Status in linux-raspi source package in Jammy: Fix Released Status in crda package in Debian: Fix Released Bug description: Debian has just removed the crda package from the archive, stating that it is obsolete with current kernels: https://bugs.debian.org/1003903 We need someone to determine if this is accurate for Ubuntu as well, and if so, update the kernel packaging to not depend on crda anymore so it can be removed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/crda/+bug/1958918/+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 1991975] Re: dev file system is mounted without nosuid or noexec
So where are we on this folks? -- 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/1991975 Title: dev file system is mounted without nosuid or noexec Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in linux source package in Focal: In Progress Status in systemd source package in Focal: Invalid Status in linux source package in Jammy: In Progress Status in systemd source package in Jammy: Invalid Bug description: [ SRU TEMPLATE ] [ Impact ] * nosuid, and noexec bits are not set on /dev * This has the potential for nefarious actors to use this as an avenue for attack. see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 for more discussion around this. * It is not best security practice. [ Test Plan ] 1.Boot a Canonical Supplied EC2 instance 2.Check the mount options for /dev. 3.You will notice the lack of nosuid and noexec on /dev. [ Where problems could occur ] * As of 2022/10/06, I need to test this, but don't know how to build -aws flavored ubuntu kernels. Instructions welcome. I'm holding off on adding SRU tags until I can actually get this tested. * If this is applied to non initramfs-less kernels it could potentially cause a regression for very old hardware that does nefarious things with memory. For a larger discussion about that see: https://lore.kernel.org/lkml/YcMfDOyrg647RCmd@debian-BULLSEYE-live-builder-AMD64/T/ * Low risk if a driver depends on /dev allowing suid or exec this might prevent boot. That being said, all kernels that have been booting with an initramfs have been getting nosuid, and noexec set so hopefully we can consider that risk fairly well tested. [ Other Info ] * Patch is accepted into 5.17, and will drop out quickly * Any server booting with an initramfs already has nosuid, and noexec set, so hopefully <<< ORIGINAL TEXT This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975/+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 1991975] Re: dev file system is mounted without nosuid or noexec
Alright so that means we either need to push a change to remove noexec from the kernel init code, or we go ahead with noexec, and give people on option to remount with exec should they want sgx functionality. I do think the nosuid flag does still provide some benefit even if we decide not to include the noexec flag by default until 5.17+. -- 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/1991975 Title: dev file system is mounted without nosuid or noexec Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in linux source package in Focal: In Progress Status in systemd source package in Focal: Invalid Status in linux source package in Jammy: In Progress Status in systemd source package in Jammy: Invalid Bug description: [ SRU TEMPLATE ] [ Impact ] * nosuid, and noexec bits are not set on /dev * This has the potential for nefarious actors to use this as an avenue for attack. see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 for more discussion around this. * It is not best security practice. [ Test Plan ] 1.Boot a Canonical Supplied EC2 instance 2.Check the mount options for /dev. 3.You will notice the lack of nosuid and noexec on /dev. [ Where problems could occur ] * As of 2022/10/06, I need to test this, but don't know how to build -aws flavored ubuntu kernels. Instructions welcome. I'm holding off on adding SRU tags until I can actually get this tested. * If this is applied to non initramfs-less kernels it could potentially cause a regression for very old hardware that does nefarious things with memory. For a larger discussion about that see: https://lore.kernel.org/lkml/YcMfDOyrg647RCmd@debian-BULLSEYE-live-builder-AMD64/T/ * Low risk if a driver depends on /dev allowing suid or exec this might prevent boot. That being said, all kernels that have been booting with an initramfs have been getting nosuid, and noexec set so hopefully we can consider that risk fairly well tested. [ Other Info ] * Patch is accepted into 5.17, and will drop out quickly * Any server booting with an initramfs already has nosuid, and noexec set, so hopefully <<< ORIGINAL TEXT This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-p
[Kernel-packages] [Bug 1991975] Re: dev file system is mounted without nosuid or noexec
In case anyone is curious conversation is on-going on the kernel-team mailing list https://lists.ubuntu.com/archives/kernel-team/2022-October/133764.html -- 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/1991975 Title: dev file system is mounted without nosuid or noexec Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in linux source package in Focal: Confirmed Status in systemd source package in Focal: Confirmed Status in linux source package in Jammy: Confirmed Status in systemd source package in Jammy: Confirmed Bug description: [ SRU TEMPLATE ] [ Impact ] * nosuid, and noexec bits are not set on /dev * This has the potential for nefarious actors to use this as an avenue for attack. see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 for more discussion around this. * It is not best security practice. [ Test Plan ] 1.Boot a Canonical Supplied EC2 instance 2.Check the mount options for /dev. 3.You will notice the lack of nosuid and noexec on /dev. [ Where problems could occur ] * As of 2022/10/06, I need to test this, but don't know how to build -aws flavored ubuntu kernels. Instructions welcome. I'm holding off on adding SRU tags until I can actually get this tested. * If this is applied to non initramfs-less kernels it could potentially cause a regression for very old hardware that does nefarious things with memory. For a larger discussion about that see: https://lore.kernel.org/lkml/YcMfDOyrg647RCmd@debian-BULLSEYE-live-builder-AMD64/T/ * Low risk if a driver depends on /dev allowing suid or exec this might prevent boot. That being said, all kernels that have been booting with an initramfs have been getting nosuid, and noexec set so hopefully we can consider that risk fairly well tested. [ Other Info ] * Patch is accepted into 5.17, and will drop out quickly * Any server booting with an initramfs already has nosuid, and noexec set, so hopefully <<< ORIGINAL TEXT This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975/+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 1991975] Re: dev file system is mounted without nosuid or noexec
@juliank, is this an aws system? If not there's a good chance that you are using an initramfs to mount the filesystems. That's definited in either /etc/init.d/udev or directly out of the init that lives in the initramfs. -- 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/1991975 Title: dev file system is mounted without nosuid or noexec Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in linux source package in Focal: Confirmed Status in systemd source package in Focal: Confirmed Status in linux source package in Jammy: Confirmed Status in systemd source package in Jammy: Confirmed Bug description: [ SRU TEMPLATE ] [ Impact ] * nosuid, and noexec bits are not set on /dev * This has the potential for nefarious actors to use this as an avenue for attack. see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 for more discussion around this. * It is not best security practice. [ Test Plan ] 1.Boot a Canonical Supplied EC2 instance 2.Check the mount options for /dev. 3.You will notice the lack of nosuid and noexec on /dev. [ Where problems could occur ] * As of 2022/10/06, I need to test this, but don't know how to build -aws flavored ubuntu kernels. Instructions welcome. I'm holding off on adding SRU tags until I can actually get this tested. * If this is applied to non initramfs-less kernels it could potentially cause a regression for very old hardware that does nefarious things with memory. For a larger discussion about that see: https://lore.kernel.org/lkml/YcMfDOyrg647RCmd@debian-BULLSEYE-live-builder-AMD64/T/ * Low risk if a driver depends on /dev allowing suid or exec this might prevent boot. That being said, all kernels that have been booting with an initramfs have been getting nosuid, and noexec set so hopefully we can consider that risk fairly well tested. [ Other Info ] * Patch is accepted into 5.17, and will drop out quickly * Any server booting with an initramfs already has nosuid, and noexec set, so hopefully <<< ORIGINAL TEXT This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975/+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 1991975] Re: dev file system is mounted without nosuid or noexec
Here is a workaround for this issue in case anyone finds this in the future. Copy remount_dev.service to /etc/systemd/system sudo chown root:root /etc/systemd/system/remount_dev.service sudo systemctl daemon-reload sudo systemctl enable remount_dev.service Still I think the kernel patch should be applied, but at least there's a workaround for now. ** Attachment added: "Systemd unit file as workaround" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975/+attachment/5622080/+files/remount_dev.service -- 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/1991975 Title: dev file system is mounted without nosuid or noexec Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in linux source package in Focal: Confirmed Status in systemd source package in Focal: Confirmed Status in linux source package in Jammy: Confirmed Status in systemd source package in Jammy: Confirmed Bug description: [ SRU TEMPLATE ] [ Impact ] * nosuid, and noexec bits are not set on /dev * This has the potential for nefarious actors to use this as an avenue for attack. see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 for more discussion around this. * It is not best security practice. [ Test Plan ] 1.Boot a Canonical Supplied EC2 instance 2.Check the mount options for /dev. 3.You will notice the lack of nosuid and noexec on /dev. [ Where problems could occur ] * As of 2022/10/06, I need to test this, but don't know how to build -aws flavored ubuntu kernels. Instructions welcome. I'm holding off on adding SRU tags until I can actually get this tested. * If this is applied to non initramfs-less kernels it could potentially cause a regression for very old hardware that does nefarious things with memory. For a larger discussion about that see: https://lore.kernel.org/lkml/YcMfDOyrg647RCmd@debian-BULLSEYE-live-builder-AMD64/T/ * Low risk if a driver depends on /dev allowing suid or exec this might prevent boot. That being said, all kernels that have been booting with an initramfs have been getting nosuid, and noexec set so hopefully we can consider that risk fairly well tested. [ Other Info ] * Patch is accepted into 5.17, and will drop out quickly * Any server booting with an initramfs already has nosuid, and noexec set, so hopefully <<< ORIGINAL TEXT This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linu
[Kernel-packages] [Bug 1991975] Re: dev file system is mounted without nosuid
** Information type changed from Private Security to Public Security ** Summary changed: - dev file system is mounted without nosuid + dev file system is mounted without nosuid or noexec -- 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/1991975 Title: dev file system is mounted without nosuid or noexec Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in linux source package in Focal: Confirmed Status in systemd source package in Focal: Confirmed Status in linux source package in Jammy: Confirmed Status in systemd source package in Jammy: Confirmed Bug description: [ SRU TEMPLATE ] [ Impact ] * nosuid, and noexec bits are not set on /dev * This has the potential for nefarious actors to use this as an avenue for attack. see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 for more discussion around this. * It is not best security practice. [ Test Plan ] 1.Boot a Canonical Supplied EC2 instance 2.Check the mount options for /dev. 3.You will notice the lack of nosuid and noexec on /dev. [ Where problems could occur ] * As of 2022/10/06, I need to test this, but don't know how to build -aws flavored ubuntu kernels. Instructions welcome. I'm holding off on adding SRU tags until I can actually get this tested. * If this is applied to non initramfs-less kernels it could potentially cause a regression for very old hardware that does nefarious things with memory. For a larger discussion about that see: https://lore.kernel.org/lkml/YcMfDOyrg647RCmd@debian-BULLSEYE-live-builder-AMD64/T/ * Low risk if a driver depends on /dev allowing suid or exec this might prevent boot. That being said, all kernels that have been booting with an initramfs have been getting nosuid, and noexec set so hopefully we can consider that risk fairly well tested. [ Other Info ] * Patch is accepted into 5.17, and will drop out quickly * Any server booting with an initramfs already has nosuid, and noexec set, so hopefully <<< ORIGINAL TEXT This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975/+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 1991975] Re: dev file system is mounted without nosuid
** Description changed: + [ SRU TEMPLATE ] + [ Impact ] + + * nosuid, and noexec bits are not set on /dev + * This has the potential for nefarious actors to use this as an avenue for attack. see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 for more discussion around this. + * It is not best security practice. + + [ Test Plan ] + +1.Boot a Canonical Supplied EC2 instance +2.Check the mount options for /dev. +3.You will notice the lack of nosuid and noexec on /dev. + + [ Where problems could occur ] + + * As of 2022/10/06, I need to test this, but don't know how to build + -aws flavored ubuntu kernels. Instructions welcome. + + * If this is applied to non initramfs-less kernels it could potentially cause a regression for very old hardware that does nefarious things with memory. For a larger discussion about that see: + https://lore.kernel.org/lkml/YcMfDOyrg647RCmd@debian-BULLSEYE-live-builder-AMD64/T/ + + * Low risk if a driver depends on /dev allowing suid or exec this might + prevent boot. That being said, all kernels that have been booting with + an initramfs have been getting nosuid, and noexec set so hopefully we + can consider that risk fairly well tested. + + [ Other Info ] + + * Patch is accepted into 5.17, and will drop out quickly + * Any server booting with an initramfs already has nosuid, and noexec set, so hopefully + + + <<< ORIGINAL TEXT + This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen ** Description changed: [ SRU TEMPLATE ] - [ Impact ] + [ Impact ] - * nosuid, and noexec bits are not set on /dev - * This has the potential for nefarious actors to use this as an avenue for attack. see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 for more discussion around this. - * It is not best security practice. + * nosuid, and noexec bits are not set on /dev + * This has the potential for nefarious actors to use this as an avenue for attack. see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 for more discussion around this. + * It is not best security practice. [ Test Plan ] -1.Boot a Canonical Supplied EC2 instance -2.Check the mount options for /dev. -3.You will notice the lack of nosuid and noexec on /dev. + 1.Boot a Canonical Supplied EC2 instance + 2.Check the mount options for /dev. + 3.You will notice the lack of nosuid and noexec on /dev. [ Where problems could occur ] - * As of 2022/10/06, I need to test this, but don't know how to build - -aws flavored ubuntu kernels. Instructions welcome. + * As of 2022/10/06, I need to test this, but don't know how to build +
[Kernel-packages] [Bug 1991975] Re: dev file system is mounted without nosuid
** Changed in: linux (Ubuntu Jammy) Status: New => Confirmed ** Changed in: systemd (Ubuntu Jammy) Status: New => 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/1991975 Title: dev file system is mounted without nosuid Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in linux source package in Focal: Confirmed Status in systemd source package in Focal: Confirmed Status in linux source package in Jammy: Confirmed Status in systemd source package in Jammy: Confirmed Bug description: This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975/+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 1991975] Re: dev file system is mounted without nosuid
** Also affects: linux (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Jammy) 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/1991975 Title: dev file system is mounted without nosuid Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in linux source package in Focal: Confirmed Status in systemd source package in Focal: Confirmed Status in linux source package in Jammy: New Status in systemd source package in Jammy: New Bug description: This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975/+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 1991975] Re: dev file system is mounted without nosuid
Looks like Kees already found this years ago. https://lore.kernel.org/lkml/YcMfDOyrg647RCmd@debian-BULLSEYE-live-builder-AMD64/T/ Looks like it was accepted as commit 28f0c335dd4a1 in 5.17. So I think we should apply this patch and the corresponding set CONFIG_DEVTMPFS_SAFE=y at least for the aws kernel and preferably all the 5.15 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/1991975 Title: dev file system is mounted without nosuid Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in linux source package in Focal: Confirmed Status in systemd source package in Focal: Confirmed Status in linux source package in Jammy: New Status in systemd source package in Jammy: New Bug description: This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975/+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 1991975] Re: dev file system is mounted without nosuid
I was hoping to work around this in /etc/init.d/udev, but it looks like that gets redirected to systemctl via . lib/lsb/init-functions ** Description changed: This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. - $ mount | grep devtmpfs - nosuid found in the options list. + $ mount | grep devtmpfs + nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: - + Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: - TERM=xterm-256color - PATH=(custom, no user) - LANG=C.UTF-8 - SHELL=/bin/bash + TERM=xterm-256color + PATH=(custom, no user) + LANG=C.UTF-8 + SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen -- 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/1991975 Title: dev file system is mounted without nosuid Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in linux source package in Focal: New Status in systemd source package in Focal: New Bug description: This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=
[Kernel-packages] [Bug 1991975] Re: dev file system is mounted without nosuid
So far I've only tested focal AWS images, but this may likely exist elsewhere as well. ** Also affects: linux (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Focal) 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/1991975 Title: dev file system is mounted without nosuid Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in linux source package in Focal: New Status in systemd source package in Focal: New Bug description: This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975/+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 1991975] Re: dev file system is mounted without nosuid
** 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/1991975 Title: dev file system is mounted without nosuid Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Bug description: This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975/+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 1901470] Re: [i915] HDMI monitor's native resolution (EDID detailed mode) not available, defaults to 1080p instead
I'm having a similar issue in Jammy again with an HDMI connected 2k monitor. The issue here being that the monitor works on boot up, but experiences this problem after a few hot plugs. Has someone found a follow-on ticket similar to this? -- 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/1901470 Title: [i915] HDMI monitor's native resolution (EDID detailed mode) not available, defaults to 1080p instead Status in linux package in Ubuntu: Confirmed Status in linux-hwe-5.11 package in Ubuntu: Confirmed Bug description: The PG278QR monitor supports 2560x1440. After installing Ubuntu 20.4, the max resolution presented in the Settings app is 1920x1080, and this resolution is the one that it uses. Switching between the Nvidia driver or the Intel driver (laptop has low-power intel gpu too) doesn't correct the problem. Digging in deeper, based on https://wiki.ubuntu.com/X/Troubleshooting/Resolution#Problem:__Wrong_resolutions.2C_refresh_rates.2C_or_monitor_specs Under Wrong resolutions/refresh rates/or monitor specs, step 3 is to use get-edid | parse-edid. After applying the mode that I wanted manually via xrandr --newmode and xrandr --addmode, I was able to select the max resolution of the monitor and works correctly, until reboot. I will add it to my xorg.conf next. Here is information I collected: output from xrandr after fresh boot: ~$ xrandr Screen 0: minimum 8 x 8, current 3840 x 1080, maximum 32767 x 32767 eDP-1-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 344mm x 193mm 1920x1080 60.01*+ 60.0159.9759.9659.93 1680x1050 59.9559.88 1600x1024 60.17 1400x1050 59.98 1600x900 59.9959.9459.9559.82 1280x1024 60.02 1440x900 59.89 1400x900 59.9659.88 1280x960 60.00 1440x810 60.0059.97 1368x768 59.8859.85 1360x768 59.8059.96 1280x800 59.9959.9759.8159.91 1152x864 60.00 1280x720 60.0059.9959.8659.74 1024x768 60.0460.00 960x720 60.00 928x696 60.05 896x672 60.01 1024x576 59.9559.9659.9059.82 960x600 59.9360.00 960x540 59.9659.9959.6359.82 800x600 60.0060.3256.25 840x525 60.0159.88 864x486 59.9259.57 800x512 60.17 700x525 59.98 800x450 59.9559.82 640x512 60.02 720x450 59.89 700x450 59.9659.88 640x480 60.0059.94 720x405 59.5158.99 684x384 59.8859.85 680x384 59.8059.96 640x400 59.8859.98 576x432 60.06 640x360 59.8659.8359.8459.32 512x384 60.00 512x288 60.0059.92 480x270 59.6359.82 400x300 60.3256.34 432x243 59.9259.57 320x240 60.05 360x202 59.5159.13 320x180 59.8459.32 HDMI-1-1 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 598mm x 336mm 1920x1080 60.00* 50.0059.94 1280x720 60.0050.0059.94 1024x768 60.00 800x600 60.32 720x576 50.00 720x480 60.0059.94 640x480 60.0059.94 DP-1-1 disconnected (normal left inverted right x axis y axis) output from get-edid | parse-edid: ~$ sudo get-edid | parse-edid This is read-edid version 3.0.2. Prepare for some fun. Attempting to use i2c interface No EDID on bus 1 No EDID on bus 2 No EDID on bus 3 No EDID on bus 5 No EDID on bus 6 No EDID on bus 7 No EDID on bus 9 No EDID on bus 10 3 potential busses found: 0 4 8 Will scan through until the first EDID is found. Pass a bus number as an option to this program to go only for that one. Bus 0 doesn't really have an EDID... 256-byte EDID successfully retrieved from i2c bus 4 Looks like i2c was successful. Have a good day. Checksum Correct Section "Monitor" Identifier "ROG PG278QR" ModelName "ROG PG278QR" VendorName "AUS" # Monitor Manufactured week 47 of 2016 # EDID version 1.3 # Digital Display DisplaySize 600 340 Gamma 2.20 Option "DPMS" "false" Horizsync 30-140 VertRefresh 24-60 # Maximum pixel clock is 300MHz #Extension block found. Parsing... Modeline"Mode 1" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync Modeline"Mode 0" 241.50 2560 2608 2640 2720 1440 1443 1448 1481 +hsync -vsyn
[Kernel-packages] [Bug 1901470] Re: [i915] HDMI monitor's native resolution (EDID detailed mode) not available, defaults to 1080p instead
** Tags added: indeed jammy -- 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/1901470 Title: [i915] HDMI monitor's native resolution (EDID detailed mode) not available, defaults to 1080p instead Status in linux package in Ubuntu: Confirmed Status in linux-hwe-5.11 package in Ubuntu: Confirmed Bug description: The PG278QR monitor supports 2560x1440. After installing Ubuntu 20.4, the max resolution presented in the Settings app is 1920x1080, and this resolution is the one that it uses. Switching between the Nvidia driver or the Intel driver (laptop has low-power intel gpu too) doesn't correct the problem. Digging in deeper, based on https://wiki.ubuntu.com/X/Troubleshooting/Resolution#Problem:__Wrong_resolutions.2C_refresh_rates.2C_or_monitor_specs Under Wrong resolutions/refresh rates/or monitor specs, step 3 is to use get-edid | parse-edid. After applying the mode that I wanted manually via xrandr --newmode and xrandr --addmode, I was able to select the max resolution of the monitor and works correctly, until reboot. I will add it to my xorg.conf next. Here is information I collected: output from xrandr after fresh boot: ~$ xrandr Screen 0: minimum 8 x 8, current 3840 x 1080, maximum 32767 x 32767 eDP-1-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 344mm x 193mm 1920x1080 60.01*+ 60.0159.9759.9659.93 1680x1050 59.9559.88 1600x1024 60.17 1400x1050 59.98 1600x900 59.9959.9459.9559.82 1280x1024 60.02 1440x900 59.89 1400x900 59.9659.88 1280x960 60.00 1440x810 60.0059.97 1368x768 59.8859.85 1360x768 59.8059.96 1280x800 59.9959.9759.8159.91 1152x864 60.00 1280x720 60.0059.9959.8659.74 1024x768 60.0460.00 960x720 60.00 928x696 60.05 896x672 60.01 1024x576 59.9559.9659.9059.82 960x600 59.9360.00 960x540 59.9659.9959.6359.82 800x600 60.0060.3256.25 840x525 60.0159.88 864x486 59.9259.57 800x512 60.17 700x525 59.98 800x450 59.9559.82 640x512 60.02 720x450 59.89 700x450 59.9659.88 640x480 60.0059.94 720x405 59.5158.99 684x384 59.8859.85 680x384 59.8059.96 640x400 59.8859.98 576x432 60.06 640x360 59.8659.8359.8459.32 512x384 60.00 512x288 60.0059.92 480x270 59.6359.82 400x300 60.3256.34 432x243 59.9259.57 320x240 60.05 360x202 59.5159.13 320x180 59.8459.32 HDMI-1-1 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 598mm x 336mm 1920x1080 60.00* 50.0059.94 1280x720 60.0050.0059.94 1024x768 60.00 800x600 60.32 720x576 50.00 720x480 60.0059.94 640x480 60.0059.94 DP-1-1 disconnected (normal left inverted right x axis y axis) output from get-edid | parse-edid: ~$ sudo get-edid | parse-edid This is read-edid version 3.0.2. Prepare for some fun. Attempting to use i2c interface No EDID on bus 1 No EDID on bus 2 No EDID on bus 3 No EDID on bus 5 No EDID on bus 6 No EDID on bus 7 No EDID on bus 9 No EDID on bus 10 3 potential busses found: 0 4 8 Will scan through until the first EDID is found. Pass a bus number as an option to this program to go only for that one. Bus 0 doesn't really have an EDID... 256-byte EDID successfully retrieved from i2c bus 4 Looks like i2c was successful. Have a good day. Checksum Correct Section "Monitor" Identifier "ROG PG278QR" ModelName "ROG PG278QR" VendorName "AUS" # Monitor Manufactured week 47 of 2016 # EDID version 1.3 # Digital Display DisplaySize 600 340 Gamma 2.20 Option "DPMS" "false" Horizsync 30-140 VertRefresh 24-60 # Maximum pixel clock is 300MHz #Extension block found. Parsing... Modeline"Mode 1" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync Modeline"Mode 0" 241.50 2560 2608 2640 2720 1440 1443 1448 1481 +hsync -vsync Modeline"Mode 2" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync Modeline"Mode 3" 74.250 1280 1390 1420 1650 720 725 730 750 +hsync +vsync Modeline
[Kernel-packages] [Bug 1977919] Re: Docker container creation causes kernel oops on linux-aws 5.13.0.1028.31~20.04.22
** Tags added: indeed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-aws-5.13 in Ubuntu. https://bugs.launchpad.net/bugs/1977919 Title: Docker container creation causes kernel oops on linux-aws 5.13.0.1028.31~20.04.22 Status in linux-aws-5.13 package in Ubuntu: Confirmed Status in linux-azure-5.13 package in Ubuntu: Confirmed Status in linux-gcp-5.13 package in Ubuntu: Confirmed Status in linux-oracle-5.13 package in Ubuntu: Confirmed Status in linux-aws-5.13 source package in Focal: In Progress Status in linux-azure-5.13 source package in Focal: In Progress Status in linux-gcp-5.13 source package in Focal: Confirmed Status in linux-oracle-5.13 source package in Focal: Confirmed Bug description: Running the attached script on the latest AWS AMI for Ubuntu 20.04, I get a kernel panic and hard reset of the node. [ 12.314552] VFS: Close: file count is 0 [ 12.351090] [ cut here ] [ 12.351093] kernel BUG at include/linux/fs.h:3104! [ 12.355272] invalid opcode: [#1] SMP PTI [ 12.358963] CPU: 1 PID: 863 Comm: sed Not tainted 5.13.0-1028-aws #31~20.04.1-Ubuntu [ 12.366241] Hardware name: Amazon EC2 m5.large/, BIOS 1.0 10/16/2017 [ 12.371130] RIP: 0010:__fput+0x247/0x250 [ 12.374897] Code: 00 48 85 ff 0f 84 8b fe ff ff f6 c7 40 0f 85 82 fe ff ff e8 ab 38 00 00 e9 78 fe ff ff 4c 89 f7 e8 2e 88 02 00 e9 b5 fe ff ff <0f> 0b 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 53 31 db 48 [ 12.389075] RSP: 0018:b50280d9fd88 EFLAGS: 00010246 [ 12.393425] RAX: RBX: 000a801d RCX: 9152e0716000 [ 12.398679] RDX: 9152cf075280 RSI: 0001 RDI: [ 12.403879] RBP: b50280d9fdb0 R08: 0001 R09: 9152dfcba2c8 [ 12.409102] R10: b50280d9fd88 R11: 9152d04e9d10 R12: 9152d04e9d00 [ 12.414333] R13: 9152dfcba2c8 R14: 9152cf0752a0 R15: 9152dfc2e180 [ 12.419533] FS: () GS:9153ea90() knlGS: [ 12.426937] CS: 0010 DS: ES: CR0: 80050033 [ 12.431506] CR2: 556cf30250a8 CR3: bce10006 CR4: 007706e0 [ 12.436716] DR0: DR1: DR2: [ 12.441941] DR3: DR6: fffe0ff0 DR7: 0400 [ 12.447170] PKRU: 5554 [ 12.450355] Call Trace: [ 12.453408] [ 12.456296] fput+0xe/0x10 [ 12.459633] task_work_run+0x70/0xb0 [ 12.463157] do_exit+0x37b/0xaf0 [ 12.466570] do_group_exit+0x43/0xb0 [ 12.470142] __x64_sys_exit_group+0x18/0x20 [ 12.473989] do_syscall_64+0x61/0xb0 [ 12.477565] ? exit_to_user_mode_prepare+0x9b/0x1c0 [ 12.481734] ? do_user_addr_fault+0x1d0/0x650 [ 12.485665] ? irqentry_exit_to_user_mode+0x9/0x20 [ 12.489790] ? irqentry_exit+0x19/0x30 [ 12.493443] ? exc_page_fault+0x8f/0x170 [ 12.497199] ? asm_exc_page_fault+0x8/0x30 [ 12.501013] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 12.505289] RIP: 0033:0x7f80d42a1bd6 [ 12.508868] Code: Unable to access opcode bytes at RIP 0x7f80d42a1bac. [ 12.513783] RSP: 002b:7ffe924f9ed8 EFLAGS: 0246 ORIG_RAX: 00e7 [ 12.520897] RAX: ffda RBX: 7f80d45a4740 RCX: 7f80d42a1bd6 [ 12.526115] RDX: RSI: 003c RDI: [ 12.531328] RBP: R08: 00e7 R09: fe98 [ 12.536484] R10: 7f80d3d422a0 R11: 0246 R12: 7f80d45a4740 [ 12.541687] R13: 0002 R14: 7f80d45ad708 R15: [ 12.546916] [ 12.549829] Modules linked in: xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo xt_addrtype iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bpfilter br_netfilter bridge stp llc aufs overlay nls_iso8859_1 dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua crct10dif_pclmul ppdev crc32_pclmul ghash_clmulni_intel aesni_intel crypto_simd psmouse cryptd parport_pc input_leds parport ena serio_raw sch_fq_codel ipmi_devintf ipmi_msghandler msr drm ip_tables x_tables autofs4 [ 12.583913] ---[ end trace 77367fed4d782aa4 ]--- [ 12.587963] RIP: 0010:__fput+0x247/0x250 [ 12.591729] Code: 00 48 85 ff 0f 84 8b fe ff ff f6 c7 40 0f 85 82 fe ff ff e8 ab 38 00 00 e9 78 fe ff ff 4c 89 f7 e8 2e 88 02 00 e9 b5 fe ff ff <0f> 0b 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 53 31 db 48 [ 12.605796] RSP: 0018:b50280d9fd88 EFLAGS: 00010246 [ 12.610166] RAX: RBX: 000a801d RCX: 9152e0716000 [ 12.615417] RDX: 9152cf075280 RSI: 0001 RDI: [ 12.620635] RBP: b50280d9fdb0 R08: 0001 R09: 9152dfcba2c8 [ 12.625878] R10: b50280
[Kernel-packages] [Bug 1977919] Re: Docker container creation causes kernel oops on linux-aws 5.13.0.1028.31~20.04.22
What are the chances we can remove the the affected kernels from the archives so more people don't get bit by this. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-aws-5.13 in Ubuntu. https://bugs.launchpad.net/bugs/1977919 Title: Docker container creation causes kernel oops on linux-aws 5.13.0.1028.31~20.04.22 Status in linux-aws-5.13 package in Ubuntu: Confirmed Status in linux-azure-5.13 package in Ubuntu: Confirmed Status in linux-gcp-5.13 package in Ubuntu: Confirmed Status in linux-oracle-5.13 package in Ubuntu: Confirmed Status in linux-aws-5.13 source package in Focal: In Progress Status in linux-azure-5.13 source package in Focal: In Progress Status in linux-gcp-5.13 source package in Focal: Confirmed Status in linux-oracle-5.13 source package in Focal: Confirmed Bug description: Running the attached script on the latest AWS AMI for Ubuntu 20.04, I get a kernel panic and hard reset of the node. [ 12.314552] VFS: Close: file count is 0 [ 12.351090] [ cut here ] [ 12.351093] kernel BUG at include/linux/fs.h:3104! [ 12.355272] invalid opcode: [#1] SMP PTI [ 12.358963] CPU: 1 PID: 863 Comm: sed Not tainted 5.13.0-1028-aws #31~20.04.1-Ubuntu [ 12.366241] Hardware name: Amazon EC2 m5.large/, BIOS 1.0 10/16/2017 [ 12.371130] RIP: 0010:__fput+0x247/0x250 [ 12.374897] Code: 00 48 85 ff 0f 84 8b fe ff ff f6 c7 40 0f 85 82 fe ff ff e8 ab 38 00 00 e9 78 fe ff ff 4c 89 f7 e8 2e 88 02 00 e9 b5 fe ff ff <0f> 0b 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 53 31 db 48 [ 12.389075] RSP: 0018:b50280d9fd88 EFLAGS: 00010246 [ 12.393425] RAX: RBX: 000a801d RCX: 9152e0716000 [ 12.398679] RDX: 9152cf075280 RSI: 0001 RDI: [ 12.403879] RBP: b50280d9fdb0 R08: 0001 R09: 9152dfcba2c8 [ 12.409102] R10: b50280d9fd88 R11: 9152d04e9d10 R12: 9152d04e9d00 [ 12.414333] R13: 9152dfcba2c8 R14: 9152cf0752a0 R15: 9152dfc2e180 [ 12.419533] FS: () GS:9153ea90() knlGS: [ 12.426937] CS: 0010 DS: ES: CR0: 80050033 [ 12.431506] CR2: 556cf30250a8 CR3: bce10006 CR4: 007706e0 [ 12.436716] DR0: DR1: DR2: [ 12.441941] DR3: DR6: fffe0ff0 DR7: 0400 [ 12.447170] PKRU: 5554 [ 12.450355] Call Trace: [ 12.453408] [ 12.456296] fput+0xe/0x10 [ 12.459633] task_work_run+0x70/0xb0 [ 12.463157] do_exit+0x37b/0xaf0 [ 12.466570] do_group_exit+0x43/0xb0 [ 12.470142] __x64_sys_exit_group+0x18/0x20 [ 12.473989] do_syscall_64+0x61/0xb0 [ 12.477565] ? exit_to_user_mode_prepare+0x9b/0x1c0 [ 12.481734] ? do_user_addr_fault+0x1d0/0x650 [ 12.485665] ? irqentry_exit_to_user_mode+0x9/0x20 [ 12.489790] ? irqentry_exit+0x19/0x30 [ 12.493443] ? exc_page_fault+0x8f/0x170 [ 12.497199] ? asm_exc_page_fault+0x8/0x30 [ 12.501013] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 12.505289] RIP: 0033:0x7f80d42a1bd6 [ 12.508868] Code: Unable to access opcode bytes at RIP 0x7f80d42a1bac. [ 12.513783] RSP: 002b:7ffe924f9ed8 EFLAGS: 0246 ORIG_RAX: 00e7 [ 12.520897] RAX: ffda RBX: 7f80d45a4740 RCX: 7f80d42a1bd6 [ 12.526115] RDX: RSI: 003c RDI: [ 12.531328] RBP: R08: 00e7 R09: fe98 [ 12.536484] R10: 7f80d3d422a0 R11: 0246 R12: 7f80d45a4740 [ 12.541687] R13: 0002 R14: 7f80d45ad708 R15: [ 12.546916] [ 12.549829] Modules linked in: xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo xt_addrtype iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bpfilter br_netfilter bridge stp llc aufs overlay nls_iso8859_1 dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua crct10dif_pclmul ppdev crc32_pclmul ghash_clmulni_intel aesni_intel crypto_simd psmouse cryptd parport_pc input_leds parport ena serio_raw sch_fq_codel ipmi_devintf ipmi_msghandler msr drm ip_tables x_tables autofs4 [ 12.583913] ---[ end trace 77367fed4d782aa4 ]--- [ 12.587963] RIP: 0010:__fput+0x247/0x250 [ 12.591729] Code: 00 48 85 ff 0f 84 8b fe ff ff f6 c7 40 0f 85 82 fe ff ff e8 ab 38 00 00 e9 78 fe ff ff 4c 89 f7 e8 2e 88 02 00 e9 b5 fe ff ff <0f> 0b 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 53 31 db 48 [ 12.605796] RSP: 0018:b50280d9fd88 EFLAGS: 00010246 [ 12.610166] RAX: RBX: 000a801d RCX: 9152e0716000 [ 12.615417] RDX: 9152cf075280 RSI: 0001 RDI: [ 12.620635] RBP:
[Kernel-packages] [Bug 1851749] Re: Frequently getting thermal warnings and cpu throttling messages in syslog
This is seems to be wider than simply Lenovo machines as my Dell Precision 5540 is hitting this as well. -- 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/1851749 Title: Frequently getting thermal warnings and cpu throttling messages in syslog Status in linux package in Ubuntu: In Progress Bug description: Nov 6 11:34:26 fog kernel: [1129655.443564] mce: CPU0: Core temperature above threshold, cpu clock throttled (total events = 50300) Nov 6 11:34:26 fog kernel: [1129655.443565] mce: CPU2: Core temperature above threshold, cpu clock throttled (total events = 50300) Nov 6 11:34:26 fog kernel: [1129655.443567] mce: CPU1: Package temperature above threshold, cpu clock throttled (total events = 58637) Nov 6 11:34:26 fog kernel: [1129655.443568] mce: CPU3: Package temperature above threshold, cpu clock throttled (total events = 58637) Nov 6 11:34:26 fog kernel: [1129655.443569] mce: CPU2: Package temperature above threshold, cpu clock throttled (total events = 58637) Nov 6 11:34:26 fog kernel: [1129655.443570] mce: CPU0: Package temperature above threshold, cpu clock throttled (total events = 58637) Nov 6 11:34:26 fog kernel: [1129655.446528] mce: CPU2: Core temperature/speed normal Nov 6 11:34:26 fog kernel: [1129655.446529] mce: CPU0: Core temperature/speed normal Nov 6 11:34:26 fog kernel: [1129655.446530] mce: CPU1: Package temperature/speed normal Nov 6 11:34:26 fog kernel: [1129655.446531] mce: CPU3: Package temperature/speed normal Nov 6 11:34:26 fog kernel: [1129655.446531] mce: CPU0: Package temperature/speed normal Nov 6 11:34:26 fog kernel: [1129655.446532] mce: CPU2: Package temperature/speed normal Nov 6 11:40:35 fog kernel: [1130024.427390] mce: CPU0: Core temperature above threshold, cpu clock throttled (total events = 50316) Nov 6 11:40:35 fog kernel: [1130024.427391] mce: CPU2: Core temperature above threshold, cpu clock throttled (total events = 50316) Nov 6 11:40:35 fog ker
[Kernel-packages] [Bug 1847786] Re: Update linux-firmware in bionic for 19.04 and 19.10 hwe kernels
** Tags added: indeed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-firmware in Ubuntu. https://bugs.launchpad.net/bugs/1847786 Title: Update linux-firmware in bionic for 19.04 and 19.10 hwe kernels Status in linux-firmware package in Ubuntu: New Bug description: It looks like the hwe kernels need the linux-firmware revved again. update-initramfs: Generating /boot/initrd.img-5.3.0-12-generic W: Possible missing firmware /lib/firmware/i915/icl_guc_32.0.3.bin for module i915 W: Possible missing firmware /lib/firmware/i915/glk_guc_32.0.3.bin for module i915 W: Possible missing firmware /lib/firmware/i915/kbl_guc_32.0.3.bin for module i915 W: Possible missing firmware /lib/firmware/i915/bxt_guc_32.0.3.bin for module i915 W: Possible missing firmware /lib/firmware/i915/skl_guc_32.0.3.bin for module i915 W: Possible missing firmware /lib/firmware/i915/icl_huc_ver8_4_3238.bin for module i915 W: Possible missing firmware /lib/firmware/i915/glk_huc_ver03_01_2893.bin for module i915 W: Possible missing firmware /lib/firmware/i915/bxt_huc_ver01_8_2893.bin for module i915 I have a feeling those with broadcom cards will also need a revved firmware in order to acquire bnx2x/bnx2x-e2-7.13.11.0.fw as they will not be able to be used with the 5.3 kernel without it. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1847786/+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 1847786] [NEW] Update linux-firmware in bionic for 19.04 and 19.10 hwe kernels
Public bug reported: It looks like the hwe kernels need the linux-firmware revved again. update-initramfs: Generating /boot/initrd.img-5.3.0-12-generic W: Possible missing firmware /lib/firmware/i915/icl_guc_32.0.3.bin for module i915 W: Possible missing firmware /lib/firmware/i915/glk_guc_32.0.3.bin for module i915 W: Possible missing firmware /lib/firmware/i915/kbl_guc_32.0.3.bin for module i915 W: Possible missing firmware /lib/firmware/i915/bxt_guc_32.0.3.bin for module i915 W: Possible missing firmware /lib/firmware/i915/skl_guc_32.0.3.bin for module i915 W: Possible missing firmware /lib/firmware/i915/icl_huc_ver8_4_3238.bin for module i915 W: Possible missing firmware /lib/firmware/i915/glk_huc_ver03_01_2893.bin for module i915 W: Possible missing firmware /lib/firmware/i915/bxt_huc_ver01_8_2893.bin for module i915 I have a feeling those with broadcom cards will also need a revved firmware in order to acquire bnx2x/bnx2x-e2-7.13.11.0.fw as they will not be able to be used with the 5.3 kernel without it. ** Affects: linux-firmware (Ubuntu) Importance: High Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-firmware in Ubuntu. https://bugs.launchpad.net/bugs/1847786 Title: Update linux-firmware in bionic for 19.04 and 19.10 hwe kernels Status in linux-firmware package in Ubuntu: New Bug description: It looks like the hwe kernels need the linux-firmware revved again. update-initramfs: Generating /boot/initrd.img-5.3.0-12-generic W: Possible missing firmware /lib/firmware/i915/icl_guc_32.0.3.bin for module i915 W: Possible missing firmware /lib/firmware/i915/glk_guc_32.0.3.bin for module i915 W: Possible missing firmware /lib/firmware/i915/kbl_guc_32.0.3.bin for module i915 W: Possible missing firmware /lib/firmware/i915/bxt_guc_32.0.3.bin for module i915 W: Possible missing firmware /lib/firmware/i915/skl_guc_32.0.3.bin for module i915 W: Possible missing firmware /lib/firmware/i915/icl_huc_ver8_4_3238.bin for module i915 W: Possible missing firmware /lib/firmware/i915/glk_huc_ver03_01_2893.bin for module i915 W: Possible missing firmware /lib/firmware/i915/bxt_huc_ver01_8_2893.bin for module i915 I have a feeling those with broadcom cards will also need a revved firmware in order to acquire bnx2x/bnx2x-e2-7.13.11.0.fw as they will not be able to be used with the 5.3 kernel without it. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1847786/+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 1729674] Re: TB16 dock ethernet corrupts data with hw checksum silently failing
@oddbjornk @cristofaro Launchpad is not a forum. Each bug is meant to solve one problem. One of you need to create a new bug for the new problem. You are welcome to reference or link this issue in that new bug though so whoever triages it has a reference. -- 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/1729674 Title: TB16 dock ethernet corrupts data with hw checksum silently failing Status in Dell Sputnik: Triaged Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Fix Released Status in linux source package in Artful: Fix Released Status in linux source package in Bionic: Fix Released Status in linux package in Fedora: Confirmed Bug description: It looks like TCP rx and tx checksum offloading is broken on the TB16 dock's ethernet adapter. For example downloading a large file such as the Ubuntu ISO, and then running an md5sum on it yields the incorrect md5sum. This is because rx-checksumming: on tx-checksumming: on and both set to on by default. Running sudo ethtool -K tx off rx off, allows the download to complete correctly. This is very bad since this can cause very bad untrustworthy behavior. This was conducted using an Dell Precision 5520 on Ubuntu 16.04+linux- generic-hwe-16.04-edge. Thank you To manage notifications about this bug go to: https://bugs.launchpad.net/dell-sputnik/+bug/1729674/+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 1702961] Re: Intel wifi instability with 4.10 and Intel Device 24fd
I'm going to close out this bug, as I have not experienced this since moving to 18.04. ** Changed in: linux (Ubuntu) Status: Confirmed => Fix Released -- 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/1702961 Title: Intel wifi instability with 4.10 and Intel Device 24fd Status in linux package in Ubuntu: Fix Released Bug description: Wifi drops and has to reconnect regularly. This is on a Dell Precision 5520. Kernel warnings in log include. [ cut here ] WARNING: CPU: 4 PID: 1042 at /build/linux-hwe-dbNd9L/linux-hwe-4.10.0/drivers/net/wireless/intel/iwlwifi/mvm/sta.c:1523 iwl_mvm_rm_sta+0x3ea/0x460 [iwlmvm] Modules linked in: ccm rfcomm bbswitch(OE) bnep snd_hda_codec_hdmi dell_led snd_hda_codec_realtek snd_hda_codec_generic hid_multitouch joydev i2c_designware_platform i2c_designware_core dell_wmi mxm_wmi nls_iso8859_1 dell_rbtn dell_laptop dell_smbios dcdbas dell_smm_hwmon intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp arc4 kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc iwlmvm aesni_intel mac80211 aes_x86_64 crypto_simd glue_helper cryptd iwlwifi cfg80211 rtsx_pci_ms memstick snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm input_leds snd_seq_midi serio_raw snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer snd soundcore uvcvideo videobuf2_vmalloc videobuf2_memops idma64 videobuf2_v4l2 virt_dma videobuf2_core videodev media btusb btrtl mei_me shpchp mei processor_thermal_device intel_lpss_pci intel_soc_dts_iosf intel_pch_thermal hci_uart btbcm btqca btintel bluetooth dell_smo8800 wmi intel_hid intel_lpss_acpi nvidia_uvm(POE) sparse_keymap mac_hid intel_lpss tpm_crb int3400_thermal int3403_thermal acpi_als int340x_thermal_zone acpi_thermal_rel kfifo_buf acpi_pad industrialio parport_pc ppdev lp parport autofs4 i915 rtsx_pci_sdmmc nvidia_drm(POE) nvidia_modeset(POE) nvidia(POE) i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops psmouse drm nvme ahci rtsx_pci nvme_core libahci i2c_hid hid pinctrl_sunrisepoint video pinctrl_intel fjes CPU: 4 PID: 1042 Comm: wpa_supplicant Tainted: P OE 4.10.0-27-generic #30~16.04.2-Ubuntu Hardware name: Dell Inc. Precision 5520/0R6JFH, BIOS 1.3.4 06/08/2017 Call Trace: dump_stack+0x63/0x90 __warn+0xcb/0xf0 warn_slowpath_null+0x1d/0x20 iwl_mvm_rm_sta+0x3ea/0x460 [iwlmvm] iwl_mvm_mac_sta_state+0x40a/0x600 [iwlmvm] drv_sta_state+0x8a/0x460 [mac80211] __sta_info_destroy_part2+0x17a/0x1b0 [mac80211] __sta_info_flush+0x103/0x1b0 [mac80211] ieee80211_set_disassoc+0xba/0x3f0 [mac80211] ieee80211_mgd_auth+0x26c/0x3c0 [mac80211] ? cfg80211_get_bss+0x1c5/0x2d0 [cfg80211] ieee80211_auth+0x18/0x20 [mac80211] cfg80211_mlme_auth+0x101/0x210 [cfg80211] nl80211_authenticate+0x30b/0x370 [cfg80211] genl_family_rcv_msg+0x1db/0x3b0 genl_rcv_msg+0x59/0xa0 ? genl_notify+0x80/0x80 netlink_rcv_skb+0xa4/0xc0 genl_rcv+0x28/0x40 netlink_unicast+0x18c/0x240 netlink_sendmsg+0x2fb/0x3a0 ? aa_sock_msg_perm+0x61/0x150 sock_sendmsg+0x38/0x50 ___sys_sendmsg+0x2c2/0x2d0 ? destroy_inode+0x3b/0x60 ? evict+0x136/0x1a0 ? iput+0x1bb/0x240 ? __dentry_kill+0x110/0x160 ? dput+0x214/0x250 ? mntput+0x24/0x40 ? __fput+0x190/0x220 __sys_sendmsg+0x54/0x90 SyS_sendmsg+0x12/0x20 entry_SYSCALL_64_fastpath+0x1e/0xad RIP: 0033:0x7f6d6dd04450 RSP: 002b:7ffcd1f168b8 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 0004 RCX: 7f6d6dd04450 RDX: RSI: 7ffcd1f16940 RDI: 0007 RBP: 562488dd1adc R08: R09: 00df R10: 1000 R11: 0246 R12: 562488dd1adc R13: 562488dd4550 R14: R15: ---[ end trace 24fe098f56796fbc ]--- ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.10.0-27-generic 4.10.0-27.30~16.04.2 [modified: boot/vmlinuz-4.10.0-27-generic] ProcVersionSignature: Ubuntu 4.10.0-27.30~16.04.2-generic 4.10.17 Uname: Linux 4.10.0-27-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.9 Architecture: amd64 CurrentDesktop: Unity Date: Fri Jul 7 11:25:55 2017 InstallationDate: Installed on 2017-07-06 (0 days ago) InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Beta amd64 (20170706) SourcePackage: linux-hwe UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1702961/+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
Re: [Kernel-packages] [Bug 1729674] Re: TB16 dock ethernet corrupts data with hw checksum silently failing
You will want to contact Dell support on that one as it appears you are running a non- Ubuntu kernel version (it's probably Dell provided). You might simply need to upgrade. On Thu, Mar 28, 2019, 3:40 PM Maxwell Ballenger wrote: > Thanks for the work you all have done tracking this down. I am > experiencing an issue with identical symptoms. I understand the problem > should be fixed with 4.15+, so I may be experiencing a different bug. If > anyone could help me determine that conclusively or point me in a > direction that might help me fix this one, I'd really appreciate it! > > Below I have reproduced the issue in the same way as above, with the > same workaround. > > Dell Precision 5530 > TB16 Dock > Ubuntu 18.04 > Kernel: 4.15.0-1034-oem > > $ sudo ethtool --offload enx3c2c30b2d39a rx on > $ for i in 1 2 3 4 5 6 7 8 9; do curl -s > http://old-releases.ubuntu.com/releases/17.04/ubuntu-17.04-server-amd64.img > -o $i.iso; md5sum $i.iso; done > 4672ce371fb3c1170a9e71bc4b2810b9 1.iso > 5cfcb270becce9962c0dc305dac943b9 2.iso > 4672ce371fb3c1170a9e71bc4b2810b9 3.iso > ba8ec5ef56501dbab731dcd0e627a334 4.iso > 7d5d892efa5899a99129d90167508434 5.iso > c0402e3a6a1179d77c3132e15af2b81f 6.iso > 4672ce371fb3c1170a9e71bc4b2810b9 7.iso > 4672ce371fb3c1170a9e71bc4b2810b9 8.iso > 4672ce371fb3c1170a9e71bc4b2810b9 9.iso > $ sudo ethtool --offload enx3c2c30b2d39a rx off > $ for i in 1 2 3 4 5 6 7 8 9; do curl -s > http://old-releases.ubuntu.com/releases/17.04/ubuntu-17.04-server-amd64.img > -o $i.iso; md5sum $i.iso; done > 4672ce371fb3c1170a9e71bc4b2810b9 1.iso > 4672ce371fb3c1170a9e71bc4b2810b9 2.iso > 4672ce371fb3c1170a9e71bc4b2810b9 3.iso > 4672ce371fb3c1170a9e71bc4b2810b9 4.iso > 4672ce371fb3c1170a9e71bc4b2810b9 5.iso > 4672ce371fb3c1170a9e71bc4b2810b9 6.iso > 4672ce371fb3c1170a9e71bc4b2810b9 7.iso > 4672ce371fb3c1170a9e71bc4b2810b9 8.iso > 4672ce371fb3c1170a9e71bc4b2810b9 9.iso > $ uname -r > 4.15.0-1034-oem > $ > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1729674 > > Title: > TB16 dock ethernet corrupts data with hw checksum silently failing > > Status in Dell Sputnik: > Triaged > Status in linux package in Ubuntu: > Fix Released > Status in linux source package in Xenial: > Fix Released > Status in linux source package in Artful: > Fix Released > Status in linux source package in Bionic: > Fix Released > Status in linux package in Fedora: > Confirmed > > Bug description: > It looks like TCP rx and tx checksum offloading is broken on the TB16 > dock's ethernet adapter. For example downloading a large file such as the > Ubuntu ISO, and then running an md5sum on it yields the incorrect md5sum. > This is because > rx-checksumming: on > tx-checksumming: on > and both set to on by default. > > Running sudo ethtool -K tx off rx off, allows the > download to complete correctly. This is very bad since this can cause > very bad untrustworthy behavior. > > This was conducted using an Dell Precision 5520 on Ubuntu 16.04+linux- > generic-hwe-16.04-edge. > > Thank you > > To manage notifications about this bug go to: > https://bugs.launchpad.net/dell-sputnik/+bug/1729674/+subscriptions > > Launchpad-Notification-Type: bug > Launchpad-Bug: product=dell-sputnik; status=Triaged; importance=High; > assignee=None; > Launchpad-Bug: distribution=ubuntu; sourcepackage=linux; component=main; > milestone=ubuntu-18.04; status=Fix Released; importance=High; assignee= > kai.heng.f...@canonical.com; > Launchpad-Bug: distribution=ubuntu; distroseries=xenial; > sourcepackage=linux; component=main; status=Fix Released; > importance=Undecided; assignee=None; > Launchpad-Bug: distribution=ubuntu; distroseries=artful; > sourcepackage=linux; component=main; status=Fix Released; importance=High; > assignee=None; > Launchpad-Bug: distribution=ubuntu; distroseries=bionic; > sourcepackage=linux; component=main; milestone=ubuntu-18.04; status=Fix > Released; importance=High; assignee=kai.heng.f...@canonical.com; > Launchpad-Bug: distribution=fedora; sourcepackage=linux; component=None; > status=Confirmed; importance=Undecided; assignee=None; > Launchpad-Bug-Tags: indeed verification-done-artful > verification-done-xenial > Launchpad-Bug-Information-Type: Public > Launchpad-Bug-Private: no > Launchpad-Bug-Security-Vulnerability: no > Launchpad-Bug-Commenters: ballengerm benjamin-redhat-bugs chiluk > christian-redhat-bugs gerben-redhat-bugs janitor jarod-redhat-bugs > jeremy-redhat-bugs jiri-redhat-bugs kai-heng-redhat-bugs kaihengfeng katamo > luciano marianne-z ma
[Kernel-packages] [Bug 1813663] Re: External monitors does not work anymore 4.15.0-44
Yah @jparedes you should probably open a different bug. You are running into something different. I've also verified that this is now fixed. -- 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/1813663 Title: External monitors does not work anymore 4.15.0-44 Status in linux package in Ubuntu: Fix Committed Status in linux source package in Bionic: Fix Released Bug description: I am using a docking station for my laptop. After install the 4.15.0-44 update my external monitors goes undetected after logging in or having the laptop closed. I am on 18.04.1 LTS with Intel® HD Graphics 620 (Kaby Lake GT2) Graphics. Going back to the 4.15.0-43 version makes it all work fine again. --- ProblemType: Bug ApportVersion: 2.20.9-0ubuntu7.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: jonas 2407 F pulseaudio CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 18.04 HibernationDevice: RESUME=UUID=80397b76-2ded-4f7d-adbf-dfdface8e2d4 InstallationDate: Installed on 2018-10-17 (103 days ago) InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) MachineType: LENOVO 20HF004MMX Package: linux (not installed) ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-44-generic root=UUID=64cf1582-d574-4e2f-a40a-7942c40caf5d ro quiet splash vt.handoff=1 ProcVersionSignature: Ubuntu 4.15.0-44.47-generic 4.15.18 RelatedPackageVersions: linux-restricted-modules-4.15.0-44-generic N/A linux-backports-modules-4.15.0-44-generic N/A linux-firmware 1.173.3 Tags: bionic Uname: Linux 4.15.0-44-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip docker kvm lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 09/14/2018 dmi.bios.vendor: LENOVO dmi.bios.version: N1WET51W (1.30 ) dmi.board.asset.tag: Not Available dmi.board.name: 20HF004MMX 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:bvrN1WET51W(1.30):bd09/14/2018:svnLENOVO:pn20HF004MMX:pvrThinkPadT470s:rvnLENOVO:rn20HF004MMX:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad T470s dmi.product.name: 20HF004MMX dmi.product.version: ThinkPad T470s dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1813663/+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 1729674] Re: TB16 dock ethernet corrupts data with hw checksum silently failing
@katamo 4.14.xx is not a supported Ubuntu kernel. I'm not sure where you pulled that kernel from, but it is not supportable. At this point all Supported Ubuntu kernels and mainline 4.15+ have this fix. @EVERYONE ELSE If you think you are hitting this issue and are running the latest supported kernels, you are likely hitting a different issue, and should be opening a new bug. Please stop resurrecting this bug. -- 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/1729674 Title: TB16 dock ethernet corrupts data with hw checksum silently failing Status in Dell Sputnik: Triaged Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Fix Released Status in linux source package in Artful: Fix Released Status in linux source package in Bionic: Fix Released Status in linux package in Fedora: Confirmed Bug description: It looks like TCP rx and tx checksum offloading is broken on the TB16 dock's ethernet adapter. For example downloading a large file such as the Ubuntu ISO, and then running an md5sum on it yields the incorrect md5sum. This is because rx-checksumming: on tx-checksumming: on and both set to on by default. Running sudo ethtool -K tx off rx off, allows the download to complete correctly. This is very bad since this can cause very bad untrustworthy behavior. This was conducted using an Dell Precision 5520 on Ubuntu 16.04+linux- generic-hwe-16.04-edge. Thank you To manage notifications about this bug go to: https://bugs.launchpad.net/dell-sputnik/+bug/1729674/+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 1729674] Re: TB16 dock ethernet corrupts data with hw checksum silently failing
Ran same tests against 4.13.0-38 on artful. Just curious, this only seems to be applied to hwe and hwe-edge kernels for xenial. Is that a change in policy? Even though I haven't attempted it, it appears as if this should be pretty straightforward apply on the 4.4 kernel stream. -- 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/1729674 Title: TB16 dock ethernet corrupts data with hw checksum silently failing Status in Dell Sputnik: Triaged Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Fix Committed Status in linux source package in Artful: Fix Committed Status in linux source package in Bionic: Fix Released Status in linux package in Fedora: Confirmed Bug description: It looks like TCP rx and tx checksum offloading is broken on the TB16 dock's ethernet adapter. For example downloading a large file such as the Ubuntu ISO, and then running an md5sum on it yields the incorrect md5sum. This is because rx-checksumming: on tx-checksumming: on and both set to on by default. Running sudo ethtool -K tx off rx off, allows the download to complete correctly. This is very bad since this can cause very bad untrustworthy behavior. This was conducted using an Dell Precision 5520 on Ubuntu 16.04+linux- generic-hwe-16.04-edge. Thank you To manage notifications about this bug go to: https://bugs.launchpad.net/dell-sputnik/+bug/1729674/+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 1729674] Re: TB16 dock ethernet corrupts data with hw checksum silently failing
** Tags removed: verification-needed-artful ** Tags added: verification-done-artful -- 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/1729674 Title: TB16 dock ethernet corrupts data with hw checksum silently failing Status in Dell Sputnik: Triaged Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Fix Committed Status in linux source package in Artful: Fix Committed Status in linux source package in Bionic: Fix Released Status in linux package in Fedora: Confirmed Bug description: It looks like TCP rx and tx checksum offloading is broken on the TB16 dock's ethernet adapter. For example downloading a large file such as the Ubuntu ISO, and then running an md5sum on it yields the incorrect md5sum. This is because rx-checksumming: on tx-checksumming: on and both set to on by default. Running sudo ethtool -K tx off rx off, allows the download to complete correctly. This is very bad since this can cause very bad untrustworthy behavior. This was conducted using an Dell Precision 5520 on Ubuntu 16.04+linux- generic-hwe-16.04-edge. Thank you To manage notifications about this bug go to: https://bugs.launchpad.net/dell-sputnik/+bug/1729674/+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 1729674] Re: TB16 dock ethernet corrupts data with hw checksum silently failing
Looks like this has been released with 4.15.0-9.10 which is available in bionic. ** Also affects: linux (Ubuntu Bionic) Importance: High Assignee: Kai-Heng Feng (kaihengfeng) Status: In Progress ** Changed in: linux (Ubuntu Bionic) Status: In Progress => Fix Released ** Changed in: linux (Ubuntu Bionic) Milestone: None => ubuntu-18.04 -- 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/1729674 Title: TB16 dock ethernet corrupts data with hw checksum silently failing Status in Dell Sputnik: Triaged Status in linux package in Ubuntu: Fix Released Status in linux source package in Artful: In Progress Status in linux source package in Bionic: Fix Released Status in linux package in Fedora: Confirmed Bug description: It looks like TCP rx and tx checksum offloading is broken on the TB16 dock's ethernet adapter. For example downloading a large file such as the Ubuntu ISO, and then running an md5sum on it yields the incorrect md5sum. This is because rx-checksumming: on tx-checksumming: on and both set to on by default. Running sudo ethtool -K tx off rx off, allows the download to complete correctly. This is very bad since this can cause very bad untrustworthy behavior. This was conducted using an Dell Precision 5520 on Ubuntu 16.04+linux- generic-hwe-16.04-edge. Thank you To manage notifications about this bug go to: https://bugs.launchpad.net/dell-sputnik/+bug/1729674/+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 1729674] Re: TB16 dock ethernet corrupts data with hw checksum silently failing
@kmously I see that you marked this fix as Fix Committed in Artful, but I do not see it in the master-next branch of artful. I'm moving this back to In progress in artful as this does not appear to have been pushed to master-next for artful yet. Feel free to push it back to Fix Committed when you accept or merge the patch into master-next. ** Changed in: linux (Ubuntu Artful) Status: Fix Committed => In Progress -- 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/1729674 Title: TB16 dock ethernet corrupts data with hw checksum silently failing Status in Dell Sputnik: Triaged Status in linux package in Ubuntu: In Progress Status in linux source package in Artful: In Progress Status in linux package in Fedora: Confirmed Bug description: It looks like TCP rx and tx checksum offloading is broken on the TB16 dock's ethernet adapter. For example downloading a large file such as the Ubuntu ISO, and then running an md5sum on it yields the incorrect md5sum. This is because rx-checksumming: on tx-checksumming: on and both set to on by default. Running sudo ethtool -K tx off rx off, allows the download to complete correctly. This is very bad since this can cause very bad untrustworthy behavior. This was conducted using an Dell Precision 5520 on Ubuntu 16.04+linux- generic-hwe-16.04-edge. Thank you To manage notifications about this bug go to: https://bugs.launchpad.net/dell-sputnik/+bug/1729674/+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 1729674] Re: TB16 dock ethernet corrupts data with hw checksum silently failing
** Changed in: linux (Ubuntu) Importance: Undecided => High ** Changed in: linux (Ubuntu Artful) Importance: Undecided => High -- 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/1729674 Title: TB16 dock ethernet corrupts data with hw checksum silently failing Status in Dell Sputnik: Triaged Status in linux package in Ubuntu: In Progress Status in linux source package in Artful: Fix Committed Status in linux package in Fedora: Confirmed Bug description: It looks like TCP rx and tx checksum offloading is broken on the TB16 dock's ethernet adapter. For example downloading a large file such as the Ubuntu ISO, and then running an md5sum on it yields the incorrect md5sum. This is because rx-checksumming: on tx-checksumming: on and both set to on by default. Running sudo ethtool -K tx off rx off, allows the download to complete correctly. This is very bad since this can cause very bad untrustworthy behavior. This was conducted using an Dell Precision 5520 on Ubuntu 16.04+linux- generic-hwe-16.04-edge. Thank you To manage notifications about this bug go to: https://bugs.launchpad.net/dell-sputnik/+bug/1729674/+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 1729674] Re: TB16 dock ethernet corrupts data with hw checksum silently failing
@pandasauce ... Fix committed means it's in the git archive, but has completed testing nor been integrated into the archives yet. Also please refrain from repeating things we already know in the thread or otherwise +1'ing or me-tooing. It just wastes developers time that could be spent actually fixing the issue. -- 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/1729674 Title: TB16 dock ethernet corrupts data with hw checksum silently failing Status in Dell Sputnik: Triaged Status in linux package in Ubuntu: In Progress Status in linux source package in Artful: Fix Committed Status in linux package in Fedora: Confirmed Bug description: It looks like TCP rx and tx checksum offloading is broken on the TB16 dock's ethernet adapter. For example downloading a large file such as the Ubuntu ISO, and then running an md5sum on it yields the incorrect md5sum. This is because rx-checksumming: on tx-checksumming: on and both set to on by default. Running sudo ethtool -K tx off rx off, allows the download to complete correctly. This is very bad since this can cause very bad untrustworthy behavior. This was conducted using an Dell Precision 5520 on Ubuntu 16.04+linux- generic-hwe-16.04-edge. Thank you To manage notifications about this bug go to: https://bugs.launchpad.net/dell-sputnik/+bug/1729674/+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 1729674] Re: TB16 dock ethernet corrupts data with hw checksum silently failing
Hasn't completed testing or been integrated into the archives. -- 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/1729674 Title: TB16 dock ethernet corrupts data with hw checksum silently failing Status in Dell Sputnik: Triaged Status in linux package in Ubuntu: In Progress Status in linux source package in Artful: Fix Committed Status in linux package in Fedora: Confirmed Bug description: It looks like TCP rx and tx checksum offloading is broken on the TB16 dock's ethernet adapter. For example downloading a large file such as the Ubuntu ISO, and then running an md5sum on it yields the incorrect md5sum. This is because rx-checksumming: on tx-checksumming: on and both set to on by default. Running sudo ethtool -K tx off rx off, allows the download to complete correctly. This is very bad since this can cause very bad untrustworthy behavior. This was conducted using an Dell Precision 5520 on Ubuntu 16.04+linux- generic-hwe-16.04-edge. Thank you To manage notifications about this bug go to: https://bugs.launchpad.net/dell-sputnik/+bug/1729674/+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 1729674] Re: TB16 dock ethernet corrupts data with hw checksum silently failing
That patch note makes it sound like there will be a hardware/firmware fix that will hopefully resolve this. If so it is very unlikely that upstream will accept your patch, as the proper fix will really be to upgrade your firmware. A more preferable patch will be to log a big bad warning if you have TB16 with the bad firmware revision. The kernel people don't tend to like to BUG hardware issues that are resolvable through firmware updates. -- 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/1729674 Title: TB16 dock ethernet corrupts data with hw checksum silently failing Status in Dell Sputnik: Triaged Status in linux package in Ubuntu: In Progress Status in linux package in Fedora: Confirmed Bug description: It looks like TCP rx and tx checksum offloading is broken on the TB16 dock's ethernet adapter. For example downloading a large file such as the Ubuntu ISO, and then running an md5sum on it yields the incorrect md5sum. This is because rx-checksumming: on tx-checksumming: on and both set to on by default. Running sudo ethtool -K tx off rx off, allows the download to complete correctly. This is very bad since this can cause very bad untrustworthy behavior. This was conducted using an Dell Precision 5520 on Ubuntu 16.04+linux- generic-hwe-16.04-edge. Thank you To manage notifications about this bug go to: https://bugs.launchpad.net/dell-sputnik/+bug/1729674/+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 1729674] Re: TB16 dock ethernet corrupts data with hw checksum silently failing
I should also mention that this should probably be pushed to linux- stable as well as mainline as this is a silent data corruption bug. -- 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/1729674 Title: TB16 dock ethernet corrupts data with hw checksum silently failing Status in Dell Sputnik: Triaged Status in linux package in Ubuntu: In Progress Status in linux package in Fedora: Confirmed Bug description: It looks like TCP rx and tx checksum offloading is broken on the TB16 dock's ethernet adapter. For example downloading a large file such as the Ubuntu ISO, and then running an md5sum on it yields the incorrect md5sum. This is because rx-checksumming: on tx-checksumming: on and both set to on by default. Running sudo ethtool -K tx off rx off, allows the download to complete correctly. This is very bad since this can cause very bad untrustworthy behavior. This was conducted using an Dell Precision 5520 on Ubuntu 16.04+linux- generic-hwe-16.04-edge. Thank you To manage notifications about this bug go to: https://bugs.launchpad.net/dell-sputnik/+bug/1729674/+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 1729674] Re: TB16 dock ethernet corrupts data with hw checksum silently failing
Those changes test as good. @Kai-Heng Feng. In the future you should consider setting LOCALVERSION or using a PPA and setting a +lp1729674 to version string in the changelog. With what you did it's hard to distinguish between your test package and an official package. See https://wiki.ubuntu.com/Kernel/Dev/KernelBugFixing#Publish_a_Package_for_Testing for more info. Thanks for the work. -- 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/1729674 Title: TB16 dock ethernet corrupts data with hw checksum silently failing Status in Dell Sputnik: Triaged Status in linux package in Ubuntu: In Progress Status in linux package in Fedora: Confirmed Bug description: It looks like TCP rx and tx checksum offloading is broken on the TB16 dock's ethernet adapter. For example downloading a large file such as the Ubuntu ISO, and then running an md5sum on it yields the incorrect md5sum. This is because rx-checksumming: on tx-checksumming: on and both set to on by default. Running sudo ethtool -K tx off rx off, allows the download to complete correctly. This is very bad since this can cause very bad untrustworthy behavior. This was conducted using an Dell Precision 5520 on Ubuntu 16.04+linux- generic-hwe-16.04-edge. Thank you To manage notifications about this bug go to: https://bugs.launchpad.net/dell-sputnik/+bug/1729674/+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 1729674] Re: TB16 dock ethernet corrupts data with hw checksum silently failing
I'm sorry I've been unable to test this from my end. Have you been able to make any progress on this? -- 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/1729674 Title: TB16 dock ethernet corrupts data with hw checksum silently failing Status in Dell Sputnik: Triaged Status in linux package in Ubuntu: In Progress Status in linux package in Fedora: Confirmed Bug description: It looks like TCP rx and tx checksum offloading is broken on the TB16 dock's ethernet adapter. For example downloading a large file such as the Ubuntu ISO, and then running an md5sum on it yields the incorrect md5sum. This is because rx-checksumming: on tx-checksumming: on and both set to on by default. Running sudo ethtool -K tx off rx off, allows the download to complete correctly. This is very bad since this can cause very bad untrustworthy behavior. This was conducted using an Dell Precision 5520 on Ubuntu 16.04+linux- generic-hwe-16.04-edge. Thank you To manage notifications about this bug go to: https://bugs.launchpad.net/dell-sputnik/+bug/1729674/+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
Re: [Kernel-packages] [Bug 1729674] Re: TB16 dock ethernet corrupts data with hw checksum silently failing
I reviewed your patch, and it appears as if it only turns off receive checksumming. The internets are saying that transmit needs to be turned off as well. Have you checked to see if transmit is affected as well? I will try to do some transmit tests. I'll also "test" your kernel when I get a chance, but by the looks of the patch there shouldn't be too much to test as it simply turns off RX checksuming which is already a known good solution. On Mon, Nov 20, 2017 at 2:06 AM, Kai-Heng Feng wrote: > Dave, > > Please try this kernel, > http://people.canonical.com/~khfeng/lp1729674/ > > The temporary workaround is what we can get before chip vendors solve > the issue. > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1729674 > > Title: > TB16 dock ethernet corrupts data with hw checksum silently failing > > Status in Dell Sputnik: > Triaged > Status in linux package in Ubuntu: > In Progress > Status in linux package in Fedora: > Confirmed > > Bug description: > It looks like TCP rx and tx checksum offloading is broken on the TB16 > dock's ethernet adapter. For example downloading a large file such as the > Ubuntu ISO, and then running an md5sum on it yields the incorrect md5sum. > This is because > rx-checksumming: on > tx-checksumming: on > and both set to on by default. > > Running sudo ethtool -K tx off rx off, allows the > download to complete correctly. This is very bad since this can cause > very bad untrustworthy behavior. > > This was conducted using an Dell Precision 5520 on Ubuntu 16.04+linux- > generic-hwe-16.04-edge. > > Thank you > > To manage notifications about this bug go to: > https://bugs.launchpad.net/dell-sputnik/+bug/1729674/+subscriptions > -- 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/1729674 Title: TB16 dock ethernet corrupts data with hw checksum silently failing Status in Dell Sputnik: Triaged Status in linux package in Ubuntu: In Progress Status in linux package in Fedora: Confirmed Bug description: It looks like TCP rx and tx checksum offloading is broken on the TB16 dock's ethernet adapter. For example downloading a large file such as the Ubuntu ISO, and then running an md5sum on it yields the incorrect md5sum. This is because rx-checksumming: on tx-checksumming: on and both set to on by default. Running sudo ethtool -K tx off rx off, allows the download to complete correctly. This is very bad since this can cause very bad untrustworthy behavior. This was conducted using an Dell Precision 5520 on Ubuntu 16.04+linux- generic-hwe-16.04-edge. Thank you To manage notifications about this bug go to: https://bugs.launchpad.net/dell-sputnik/+bug/1729674/+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 1729674] Re: TB16 dock ethernet corrupts data with hw checksum silently failing
udevadm info -e as requested. ** Attachment added: "udevadminfo" https://bugs.launchpad.net/dell-sputnik/+bug/1729674/+attachment/5010640/+files/udevadminfo -- 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/1729674 Title: TB16 dock ethernet corrupts data with hw checksum silently failing Status in Dell Sputnik: Triaged Status in linux package in Ubuntu: In Progress Status in linux package in Fedora: Confirmed Bug description: It looks like TCP rx and tx checksum offloading is broken on the TB16 dock's ethernet adapter. For example downloading a large file such as the Ubuntu ISO, and then running an md5sum on it yields the incorrect md5sum. This is because rx-checksumming: on tx-checksumming: on and both set to on by default. Running sudo ethtool -K tx off rx off, allows the download to complete correctly. This is very bad since this can cause very bad untrustworthy behavior. This was conducted using an Dell Precision 5520 on Ubuntu 16.04+linux- generic-hwe-16.04-edge. Thank you To manage notifications about this bug go to: https://bugs.launchpad.net/dell-sputnik/+bug/1729674/+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 1729674] Re: TB16 dock ethernet corrupts data with hw checksum silently failing
I also just went through the process of reproducing this while watching the kern.log. Absolutely 0 messages came out. If you find some verbose debugging you want me to turn on let me know. -- 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/1729674 Title: TB16 dock ethernet corrupts data with hw checksum silently failing Status in Dell Sputnik: Triaged Status in linux package in Ubuntu: In Progress Bug description: It looks like TCP rx and tx checksum offloading is broken on the TB16 dock's ethernet adapter. For example downloading a large file such as the Ubuntu ISO, and then running an md5sum on it yields the incorrect md5sum. This is because rx-checksumming: on tx-checksumming: on and both set to on by default. Running sudo ethtool -K tx off rx off, allows the download to complete correctly. This is very bad since this can cause very bad untrustworthy behavior. This was conducted using an Dell Precision 5520 on Ubuntu 16.04+linux- generic-hwe-16.04-edge. Thank you To manage notifications about this bug go to: https://bugs.launchpad.net/dell-sputnik/+bug/1729674/+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
Re: [Kernel-packages] [Bug 1729674] Re: TB16 dock ethernet corrupts data with hw checksum silently failing
I am not using ipv6. On Tue, Nov 14, 2017 at 9:10 AM, Mario Limonciello wrote: > @Dave: > > I was glancing at r8152 driver and notice that it has some special > handling for ipv6. Is this issue reproducing only in ipv6 for you? > https://github.com/torvalds/linux/commit/6128d1bb30748d0ff56a63898d14f3 > 12126e404c > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1729674 > > Title: > TB16 dock ethernet corrupts data with hw checksum silently failing > > Status in Dell Sputnik: > Triaged > Status in linux package in Ubuntu: > In Progress > > Bug description: > It looks like TCP rx and tx checksum offloading is broken on the TB16 > dock's ethernet adapter. For example downloading a large file such as the > Ubuntu ISO, and then running an md5sum on it yields the incorrect md5sum. > This is because > rx-checksumming: on > tx-checksumming: on > and both set to on by default. > > Running sudo ethtool -K tx off rx off, allows the > download to complete correctly. This is very bad since this can cause > very bad untrustworthy behavior. > > This was conducted using an Dell Precision 5520 on Ubuntu 16.04+linux- > generic-hwe-16.04-edge. > > Thank you > > To manage notifications about this bug go to: > https://bugs.launchpad.net/dell-sputnik/+bug/1729674/+subscriptions > -- 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/1729674 Title: TB16 dock ethernet corrupts data with hw checksum silently failing Status in Dell Sputnik: Triaged Status in linux package in Ubuntu: In Progress Bug description: It looks like TCP rx and tx checksum offloading is broken on the TB16 dock's ethernet adapter. For example downloading a large file such as the Ubuntu ISO, and then running an md5sum on it yields the incorrect md5sum. This is because rx-checksumming: on tx-checksumming: on and both set to on by default. Running sudo ethtool -K tx off rx off, allows the download to complete correctly. This is very bad since this can cause very bad untrustworthy behavior. This was conducted using an Dell Precision 5520 on Ubuntu 16.04+linux- generic-hwe-16.04-edge. Thank you To manage notifications about this bug go to: https://bugs.launchpad.net/dell-sputnik/+bug/1729674/+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 1674680] Re: Deprecated rfcomm.conf still mentioned in bluetooth.conf and README
Sponsored artful. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1674680 Title: Deprecated rfcomm.conf still mentioned in bluetooth.conf and README Status in bluez package in Ubuntu: New Status in bluez source package in Xenial: New Status in bluez source package in Yakkety: Won't Fix Status in bluez source package in Artful: New Status in bluez package in Debian: New Bug description: [Impact] * The package contains misleading documentation mentioning the use of /etc/bluetooth/rfcomm.conf for rfcomm setup while the support for config file has been dropped after 14.04 release. I have directly received a question about it from a user mislead by the documentation. * Additionally deprecated -f option is still used in legacy upstart /etc/init/bluetooth.conf. Actually this does not seem longer required due to upstart being removed. [Test Case] * Install bluez. * Look for misleading rfcomm.conf mentions in /etc/init/bluetooth.conf, /usr/share/doc/bluez/README.Debian.gz [Regression Potential] * This is mostly a documentation correction, however if somebody still depends bluetooth started with Ubuntu 16.04+ by upstart (or possibly some kind of upstart compatibility in systemd, is that even possible?) he/she may end up with bluetooth not being started. This seems highly unlikely. [Other Info] * Original bug description: Support for config files has been dropped upstream in 2012 (however version shipped with Trusty still supports it), but the latest versions (including Xenial and Zesty) still mention it in the docs and in the legacy /etc/init/bluetooth.conf file. Additionally the /etc/init/bluetooth.conf don't seem necessary these days. In fact it has been dropped by Debian already. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1674680/+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 1674680] Re: Deprecated rfcomm.conf still mentioned in bluetooth.conf and README
** Also affects: bluez (Ubuntu Artful) Importance: Low Status: New ** Tags removed: sts-sponsor-chiluk -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1674680 Title: Deprecated rfcomm.conf still mentioned in bluetooth.conf and README Status in bluez package in Ubuntu: New Status in bluez source package in Xenial: New Status in bluez source package in Yakkety: Won't Fix Status in bluez source package in Artful: New Status in bluez package in Debian: New Bug description: [Impact] * The package contains misleading documentation mentioning the use of /etc/bluetooth/rfcomm.conf for rfcomm setup while the support for config file has been dropped after 14.04 release. I have directly received a question about it from a user mislead by the documentation. * Additionally deprecated -f option is still used in legacy upstart /etc/init/bluetooth.conf. Actually this does not seem longer required due to upstart being removed. [Test Case] * Install bluez. * Look for misleading rfcomm.conf mentions in /etc/init/bluetooth.conf, /usr/share/doc/bluez/README.Debian.gz [Regression Potential] * This is mostly a documentation correction, however if somebody still depends bluetooth started with Ubuntu 16.04+ by upstart (or possibly some kind of upstart compatibility in systemd, is that even possible?) he/she may end up with bluetooth not being started. This seems highly unlikely. [Other Info] * Original bug description: Support for config files has been dropped upstream in 2012 (however version shipped with Trusty still supports it), but the latest versions (including Xenial and Zesty) still mention it in the docs and in the legacy /etc/init/bluetooth.conf file. Additionally the /etc/init/bluetooth.conf don't seem necessary these days. In fact it has been dropped by Debian already. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1674680/+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 1259829] Re: htree_dirblock_to_tree:920: inode #53629599: block 214443464: comm rm: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=1667681412, rec_len=45654, name
@bybeu, please do not post questions like this to ancient bugs. Instead use askubuntu or ubuntuforums. Back to your problem at hand though. You are free to manually add your ssd's to the whitelist. Unfortunately the way you asked your question makes it very unclear what you've done or what your problem is. In case you are wondering, in 16.04 it looks like the whitelist is no longer utilized. -- 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/1259829 Title: htree_dirblock_to_tree:920: inode #53629599: block 214443464: comm rm: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=1667681412, rec_len=45654, name_len=39 Status in linux package in Ubuntu: Fix Released Bug description: fs goes into read-only mode while building LibreOffice. WORKAROUND: Disable discard option - /dev/mapper/volumegroup-root/ ext4discard,noatime,nodiratime,errors=remount-ro01 disabling ncq has no effect. $ dmesg ... [ 2045.473249] virbr0: port 1(vnet0) entered forwarding state [ 2045.473283] IPv6: ADDRCONF(NETDEV_CHANGE): virbr0: link becomes ready [10660.961381] perf samples too long (2505 > 2500), lowering kernel.perf_event_max_sample_rate to 5 [11822.935891] EXT4-fs error (device dm-1): htree_dirblock_to_tree:920: inode #53629599: block 214443464: comm rm: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=1667681412, rec_len=45654, name_len=39 [11822.935896] Aborting journal on device dm-1-8. [11822.935998] EXT4-fs (dm-1): Remounting filesystem read-only [11822.960425] EXT4-fs error (device dm-1): htree_dirblock_to_tree:920: inode #53629605: block 214443466: comm rm: bad entry in directory: directory entry across range - offset=0(0), inode=2707156714, rec_len=19312, name_len=162 [11850.985003] EXT4-fs error (device dm-1): htree_dirblock_to_tree:920: inode #53629557: block 214443458: comm rm: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=512948573, rec_len=8858, name_len=176 [11850.985276] EXT4-fs error (device dm-1): htree_dirblock_to_tree:920: inode #53629465: block 214443455: comm rm: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=160939375, rec_len=26085, name_len=126 [11850.985499] EXT4-fs error (device dm-1): htree_dirblock_to_tree:920: inode #53629325: block 214443451: comm rm: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=2322664969, rec_len=33791, name_len=132 [11850.985927] EXT4-fs error (device dm-1): htree_dirblock_to_tree:920: inode #53629467: block 214443456: comm rm: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=954332768, rec_len=21653, name_len=30 [11850.986409] EXT4-fs error (device dm-1): htree_dirblock_to_tree:920: inode #53629074: block 214443433: comm rm: bad entry in directory: directory entry across range - offset=0(0), inode=2061605548, rec_len=4984, name_len=3 [11850.986831] EXT4-fs error (device dm-1): htree_dirblock_to_tree:920: inode #53628835: block 214443432: comm rm: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=3523041938, rec_len=53167, name_len=41 [11850.987001] EXT4-fs error (device dm-1): htree_dirblock_to_tree:920: inode #53629098: block 214443436: comm rm: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=4225920287, rec_len=35138, name_len=75 [11850.987466] EXT4-fs error (device dm-1): htree_dirblock_to_tree:920: inode #53629275: block 214443449: comm rm: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=923253145, rec_len=44001, name_len=144 [11850.988115] EXT4-fs error (device dm-1): htree_dirblock_to_tree:920: inode #53629270: block 214443448: comm rm: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=1892288796, rec_len=55247, name_len=58 [11851.042303] EXT4-fs error (device dm-1): htree_dirblock_to_tree:920: inode #53629300: block 214443450: comm rm: bad entry in directory: directory entry across range - offset=0(0), inode=1809316884, rec_len=4208, name_len=195 [11851.042938] EXT4-fs error (device dm-1): htree_dirblock_to_tree:920: inode #53629401: block 214443453: comm rm: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=4223616103, rec_len=36326, name_len=130 [11851.045745] EXT4-fs error (device dm-1): htree_dirblock_to_tree:920: inode #53629406: block 214443454: comm rm: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=415237227, rec_len=24702, name_len=59 [11851.125849] EXT4-fs error (device dm-1): htree_dirblock_to_tree:920: inode #53629101: block 214443437: comm rm: bad entry in directory: directory entry across range - offset=0(0), inode=23292377, rec_len=28820, name_len=135 [11851.126086] EXT4-fs error (device dm-1): htree_dirblock_to_tree:920: inode #53629543: block 214443457: comm rm: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=2624043515, rec_len=58633, name_len=250 [1
[Kernel-packages] [Bug 1705054] Re: Trusty kexec-tools suffer from upstream code regression. Fix not included.
@slashd beat me to the upload, but it looks good to me. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to kexec-tools in Ubuntu. https://bugs.launchpad.net/bugs/1705054 Title: Trusty kexec-tools suffer from upstream code regression. Fix not included. Status in kexec-tools package in Ubuntu: Fix Released Status in kexec-tools source package in Trusty: In Progress Bug description: [Impact] * kdump doesn't work on non-efi systems * a kernel dump can't be generated [Test Case] * install kdump-tools * configure kdump-tools (/etc/default/kdump-tools) * try to start kdump-tools service (kdump-config start) * while executing kexec, you will get: "efi memory descriptor version 0 is not supported!" [Regression Potential] * in theory it could brake kdump for efi systems * in practice, its based on upstream regression fix (not included in Trusty) * it has also been tested in 3 different setups and it worked [Other Info] Based on upstream code commit explanation: """ On non-EFI systems, efi_info section of boot_params is zero filled resulting in an erroneous message from kexec regarding "efi memory descriptor" version. Caused by commit: e1ffc9e9a0769e1f54185003102e9bec428b84e8 "Passing efi related data via setup_data" # od -j 448 -N 32 -v -x /sys/kernel/boot_params/data 700 720 740 # kexec -l --reuse-cmdline --initrd=/boot/initrd-`uname -r` /boot/vmlinuz-`uname -r` efi memory descriptor version 0 is not supported! """ It was brought to my attention to some of our users are facing this: ## TRUSTY with kernel 4.4.0-83-generic # /usr/sbin/kdump-config load efi memory descriptor version 0 is not supported! * loaded kdump kernel /var/log/syslog: Jul 18 13:37:06 kdump-config: /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-4.4.0-83-generic root=UUID=-20e4-4325-ad92-7aef2af0beac ro KDUMP_CMDLINE_APPEND=irqpoll maxcpus=1 nousb irqpoll maxcpus=1 nousb" --initrd=/boot/initrd.img-4.4.0-83-generic /boot/vmlinuz-4.4.0-83-generic Jul 18 13:37:06 kdump-config: loaded kdump kernel Despite the message of kdump being loaded, it doesn't look that it is operational. Dump files could be generated using Xenial kdump-tools, but not Trusty's. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1705054/+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 1458204] Re: removing kernels should not require a restart afterward
** Tags added: indeed -- 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/1458204 Title: removing kernels should not require a restart afterward Status in unattended-upgrades: New Status in update notifier: New Status in linux package in Ubuntu: Confirmed Status in unattended-upgrades package in Ubuntu: Confirmed Status in update-notifier package in Ubuntu: Confirmed Status in linux source package in Artful: Confirmed Status in unattended-upgrades source package in Artful: Confirmed Status in update-notifier source package in Artful: Confirmed Bug description: 1. Perform a kernel upgrade normally via "apt-get dist-upgrade". 2. Reboot. 3. Run "apt-get autoremove" to delete the old kernel packages. 4. "System Notification Helper" now reports that the computer requires a reboot. The "autoremove" operation shouldn't require a reboot, logically speaking, because it's just removing files that are unused by the OS. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: apt 1.0.1ubuntu2.7 ProcVersionSignature: Ubuntu 3.13.0-53.89-generic 3.13.11-ckt19 Uname: Linux 3.13.0-53-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.11 Architecture: amd64 CurrentDesktop: KDE Date: Sat May 23 12:47:15 2015 InstallationDate: Installed on 2013-08-31 (629 days ago) InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424) SourcePackage: apt UpgradeStatus: Upgraded to trusty on 2014-04-26 (391 days ago) --- ApportVersion: 2.14.1-0ubuntu3.11 Architecture: amd64 CurrentDesktop: KDE DistroRelease: Ubuntu 14.04 HibernationDevice: RESUME=UUID=66f11ff7-00bb-4452-9168-003cf9078308 InstallationDate: Installed on 2013-08-31 (632 days ago) InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424) MachineType: System manufacturer System Product Name Package: linux (not installed) ProcFB: 0 nouveaufb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-53-generic root=UUID=02741f1f-8107-4a0f-b9a6-31ef470b1389 ro libata.force=noncq quiet splash vt.handoff=7 ProcVersionSignature: Ubuntu 3.13.0-53.89-generic 3.13.11-ckt19 RelatedPackageVersions: linux-restricted-modules-3.13.0-53-generic N/A linux-backports-modules-3.13.0-53-generic N/A linux-firmware 1.127.12 RfKill: Tags: trusty Uname: Linux 3.13.0-53-generic x86_64 UpgradeStatus: Upgraded to trusty on 2014-04-26 (395 days ago) UserGroups: adm cdrom dialout dip fuse lightdm lpadmin plugdev sambashare sudo WifiSyslog: _MarkForUpload: True dmi.bios.date: 08/12/2013 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 4210 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: P9X79 dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev 1.xx dmi.chassis.asset.tag: Asset-1234567890 dmi.chassis.type: 3 dmi.chassis.vendor: Chassis Manufacture dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4210:bd08/12/2013:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnP9X79:rvrRev1.xx:cvnChassisManufacture:ct3:cvrChassisVersion: dmi.product.name: System Product Name dmi.product.version: System Version dmi.sys.vendor: System manufacturer To manage notifications about this bug go to: https://bugs.launchpad.net/unattended-upgrades/+bug/1458204/+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 1690512] Re: shutdown/restart/suspend freezes laptop on intel graphics
Please try the latest hwe stack by. I'm using kabylake + the hwe stack without issue at the moment. sudo apt install --install-recommends linux-generic-hwe-16.04 xserver- xorg-hwe-16.04 More info is available here. https://wiki.ubuntu.com/Kernel/LTSEnablementStack I'm also closing the intel-microcode track of this bug as at the moment this does not appear to be hwe related. Thank you, ** Changed in: intel-microcode (Ubuntu) Status: New => Invalid -- 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/1690512 Title: shutdown/restart/suspend freezes laptop on intel graphics Status in intel-microcode package in Ubuntu: Invalid Status in linux package in Ubuntu: Confirmed Status in xorg package in Ubuntu: New Bug description: I'm not sure where to report this under, so please bear with me. Reporting this bug using ubuntu-bug just crashes my system if im using intel graphics, I had to switch to nvidia graphics just to file this bug report so the automatically attached log files may not be a good representation of the problem. I've attached the syslog and kern.log files below. PROBLEM: When using intel graphics: Whenever I close the laptop lid or restart / shutdown using GUI or terminal commands, it goes into a black screen with a single "_" at the top left corner, and hangs. Only long-pressing (hard reset) the power button would shut down the computer. However, when I use sudo prime-select nvidia to switch over to nvidia, everything works fine.log I have tried many things, and all do not work. I have attached the logs for /var/log/syslog and /var/log/kern.log below. Attempts so far: 1)Tried installing new intel drivers from Updated kernel to 4.8 now missing firmware warnings --> Did not work. Issue persists 2) Tried upgrading kernel from 4.8 to 4.10.15 --> Did not work. Problem got worse. Instead of the normal login screen, it gives a terminal login screen and hangs. 3) Tried the fix to nvidia-prime https://askubuntu.com/a/884506/547039, but both the poweron.sh and poweroff.sh script hangs my laptop instead. 4) Tried sudo swapoff -a && systemctl poweroff as a workaround, no avail. 5) Tried changing GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" to GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi=force" Does not work either. Additional note: 'sudo lshw -C display' on intel graphics outputs PCI(sysfs) then laptop freezes. LOG FILES: /var/log/syslog https://codeshare.io/5XOPwM /var/log/kern.log https://codeshare.io/aJp6nq specs: Intel 7700HQ, NVIDIA 1060GTX, kernel 4.8, Ubuntu 16.04 Would really appreciate your help. Thank you! ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: xorg 1:7.7+13ubuntu3 ProcVersionSignature: Ubuntu 4.8.0-51.54~16.04.1-generic 4.8.17 Uname: Linux 4.8.0-51-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia .proc.driver.nvidia.gpus..01.00.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/:01:00.0' .proc.driver.nvidia.registry: Binary: "" .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 381.22 Thu May 4 00:55:03 PDT 2017 GCC version: gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) .tmp.unity_support_test.0: ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: compiz CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0' CompositorUnredirectFSW: true CurrentDesktop: Unity Date: Sat May 13 17:06:20 2017 DistUpgraded: Fresh install DistroCodename: xenial DistroVariant: ubuntu DkmsStatus: bbswitch, 0.8, 4.4.0-77-generic, x86_64: installed bbswitch, 0.8, 4.8.0-49-generic, x86_64: installed bbswitch, 0.8, 4.8.0-51-generic, x86_64: installed nvidia-381, 381.22, 4.8.0-51-generic, x86_64: installed EcryptfsInUse: Yes ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation Device [8086:591b] (rev 04) (prog-if 00 [VGA controller]) Subsystem: CLEVO/KAPOK Computer Device [1558:65a1] NVIDIA Corporation Device [10de:1c20] (rev a1) (prog-if 00 [VGA controller]) Subsystem: CLEVO/KAPOK Computer Device [1558:65a1] InstallationDate: Installed on 2017-03-30 (43 days ago) InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 (20170215.2) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 004: ID 04f2:b5a7 Chicony Electronics Co., Ltd Bus 001 Device 003: ID 8087:0a2b Intel Corp. Bus 001 Device 002: ID 0483:374b STMicroelectronics ST-LINK/V2.1 (Nucleo-F103RB) Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Aftershock P65xHP ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.8.0-51-generic root=/dev/mapper/u
[Kernel-packages] [Bug 1591669] Re: duplicate touchpad reported and syndaemon/synclient does not work
** Tags added: indeed -- 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/1591669 Title: duplicate touchpad reported and syndaemon/synclient does not work Status in linux package in Ubuntu: Confirmed Bug description: This is on a Dell XPS 13 9350 DE running ubuntu 16.04. This laptop has a touchpad and a touchscreen. I'm reporting here about the touchpad. One can see from Xorg.0.log and "xinput list" that *two* touchpads are registered by the system one is called "DLL0704:01 06CB:76AE Touchpad" and the other "SynPS/2 Synaptics TouchPad" As a result, syndaemon is not working. To check this, open two terminals, press and hold some key, like "e" in one of them. It starts filling with "eee". Now while holding the key, use the touchpad to tap on the other terminal. Then "" fills the new terminal. Expected behaviour: tapping on the other terminal should have no effet, the "e"'s should continue to fill the first terminal. Moreover, configuring the touchpad with synclient is not working either. FIX: Since invoking xinput disable "SynPS/2 Synaptics TouchPad" has no effect, it is clear that this one is a "false" touchpad. Hence this fix is: Add an "ignore" section in /usr/share/X11/xorg.conf.d/50-synaptics.conf I added, line 29: Section "InputClass" Identifier "touchpad ignore SynPS/2 Synaptics duplicate" MatchProduct "SynPS/2 Synaptics TouchPad" Option "Ignore" "on" EndSection Now it works. The touchpad is correctly disabled when using the keyboard, and moreover I can configure it using synclient, or adding a file to /etc/X11/xorg.conf.d/ Of course this fix is not universal because I had to use the precise name of the "false touchpad" as reported by xinput. --- ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: san1697 F pulseaudio CurrentDesktop: Unity DistroRelease: Ubuntu 16.04 HibernationDevice: RESUME=UUID=0dbbd1c1-bb58-45af-8c68-716d7ae636e7 InstallationDate: Installed on 2016-06-03 (9 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 004: ID 0c45:670c Microdia Bus 001 Device 003: ID 04f3:20d0 Elan Microelectronics Corp. Bus 001 Device 002: ID 8087:0a2b Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Dell Inc. XPS 13 9350 Package: linux (not installed) ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-24-generic.efi.signed root=UUID=75dd5fb6-2ff1-4f2b-859d-4c3942a5c45b ro quiet splash vt.handoff=7 ProcVersionSignature: Ubuntu 4.4.0-24.43-generic 4.4.10 RelatedPackageVersions: linux-restricted-modules-4.4.0-24-generic N/A linux-backports-modules-4.4.0-24-generic N/A linux-firmware1.157 Tags: xenial Uname: Linux 4.4.0-24-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 03/01/2016 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.3.3 dmi.board.name: 09JHRY dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.3.3:bd03/01/2016:svnDellInc.:pnXPS139350:pvr:rvnDellInc.:rn09JHRY:rvrA00:cvnDellInc.:ct9:cvr: dmi.product.name: XPS 13 9350 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1591669/+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 1527062] Re: XFS Deadlock on 4.2+
@lordbaco, are you still hitting this? Also please post your entire oops next time, as I can't do much with what you've posted. Also you might want to try moving up to the 4.4 kernel by installing linux-image-lts-xenial on trusty *(I think that's the package name). Marking this as fixed release, unless someone screams. ** Changed in: linux (Ubuntu) Status: In Progress => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-lts-utopic in Ubuntu. https://bugs.launchpad.net/bugs/1527062 Title: XFS Deadlock on 4.2+ Status in linux package in Ubuntu: Fix Released Status in linux-lts-utopic package in Ubuntu: Invalid Status in linux source package in Trusty: Fix Released Status in linux-lts-utopic source package in Trusty: Fix Committed Status in linux source package in Vivid: Fix Released Status in linux-lts-utopic source package in Vivid: Invalid Status in linux source package in Wily: Fix Released Status in linux-lts-utopic source package in Wily: Invalid Bug description: [Impact] * An XFS Deadlock situation is possible on kernels older than 4.4rc1^ * Hung tasks have stack traces similar to [ 4559.110607] INFO: task kworker/1:0:17 blocked for more than 120 seconds. [ 4559.143010] Not tainted 4.2.0-18-generic #22~14.04.1-Ubuntu [ 4559.171972] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 4559.209753] kworker/1:0 D 017 2 0x [ 4559.209791] Workqueue: xfs-cil/sdac1 xlog_cil_push_work [xfs] [ 4559.209794] 88085be9fbb8 0046 88085b746040 88085be8a940 [ 4559.209795] 88085bea 880107fddcc0 88085be8a940 [ 4559.209797] 880859119c00 880859119d00 88085be9fbd8 817b6a77 [ 4559.209798] Call Trace: [ 4559.209806] [] schedule+0x37/0x80 [ 4559.209817] [] xlog_state_get_iclog_space+0xdb/0x2d0 [xfs] [ 4559.209822] [] ? wake_up_q+0x80/0x80 [ 4559.209832] [] xlog_write+0x191/0x6a0 [xfs] [ 4559.209835] [] ? prandom_u32+0x18/0x20 [ 4559.209845] [] xlog_cil_push+0x1f9/0x3b0 [xfs] [ 4559.209854] [] xlog_cil_push_work+0x15/0x20 [xfs] [ 4559.209857] [] process_one_work+0x14e/0x3d0 [ 4559.209858] [] worker_thread+0x11a/0x470 [ 4559.209860] [] ? rescuer_thread+0x310/0x310 [ 4559.209862] [] kthread+0xd2/0xf0 [ 4559.209863] [] ? kthread_create_on_node+0x1c0/0x1c0 [ 4559.209865] [] ret_from_fork+0x3f/0x70 [ 4559.209866] [] ? kthread_create_on_node+0x1c0/0x1c0 or [305651.804853] INFO: task kswapd0:194 blocked for more than 120 seconds. [305651.836092] Not tainted 4.2.0-18-generic #22~14.04.1-Ubuntu [305651.865655] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [305651.903596] kswapd0 D 88085fa96640 0 194 2 0x [305651.903614] 8810591ab858 0046 88085c2c2940 88105b19a940 [305651.903616] 880066c64548 8810591ac000 8808599cae18 [305651.903618] 88105b19a940 88085a2cb000 8810591ab878 817b6a77 [305651.903620] Call Trace: [305651.903629] [] schedule+0x37/0x80 [305651.903655] [] _xfs_log_force_lsn+0x15c/0x2d0 [xfs] [305651.903662] [] ? wake_up_q+0x80/0x80 [305651.903675] [] xfs_log_force_lsn+0x2e/0x80 [xfs] [305651.903687] [] ? xfs_iunpin_wait+0x19/0x20 [xfs] [305651.903698] [] __xfs_iunpin_wait+0x8d/0x120 [xfs] [305651.903701] [] ? autoremove_wake_function+0x40/0x40 [305651.903711] [] xfs_iunpin_wait+0x19/0x20 [xfs] [305651.903721] [] xfs_reclaim_inode+0x125/0x330 [xfs] [305651.903732] [] xfs_reclaim_inodes_ag+0x248/0x360 [xfs] [305651.903735] [] ? destroy_inode+0x3c/0x60 [305651.903744] [] xfs_reclaim_inodes_nr+0x33/0x40 [xfs] [305651.903755] [] xfs_fs_free_cached_objects+0x19/0x20 [xfs] [305651.903758] [] super_cache_scan+0x181/0x190 [305651.903761] [] shrink_slab+0x206/0x380 [305651.903763] [] shrink_zone+0x291/0x2b0 [305651.903764] [] kswapd+0x500/0x9b0 [305651.903766] [] ? mem_cgroup_shrink_node_zone+0x130/0x130 [305651.903768] [] kthread+0xd2/0xf0 [305651.903770] [] ? kthread_create_on_node+0x1c0/0x1c0 [305651.903772] [] ret_from_fork+0x3f/0x70 [305651.903774] [] ? kthread_create_on_node+0x1c0/0x1c0 [Test Case] * Large numbers of IO tasks to large numbers of XFS fileystems while under memory pressure. Testcase may not be guaranteed. [Regression Potential] * Upstream commit https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7a29ac474a47eb8cf212b45917683ae89d6fa13b - This commit allocates rescuer threads for each of the XFS work queues. * Possible additional memory usage from rescuer threads. [Other Info] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1527062/+subscriptions -- Mail
[Kernel-packages] [Bug 1674680] Re: Deprecated rfcomm.conf still mentioned
Just so you know I'm waiting for zesty release before uploading this. I don't want to risk causing issues on the release media. Additionally policy is to only push high priority bug fixes for the few weeks leading up to release. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1674680 Title: Deprecated rfcomm.conf still mentioned Status in bluez package in Ubuntu: New Status in bluez source package in Xenial: New Status in bluez source package in Yakkety: New Bug description: [Impact] * The package contains misleading documentation mentioning the use of /etc/bluetooth/rfcomm.conf for rfcomm setup while the support for config file has been dropped after 14.04 release. I have directly received a question about it from a user mislead by the documentation. * Additionally deprecated -f option is still used in legacy upstart /etc/init/bluetooth.conf. Actually this does not seem longer required due to upstart being removed. [Test Case] * Install bluez. * Look for misleading rfcomm.conf mentions in /etc/init/bluetooth.conf, /usr/share/doc/bluez/README.Debian.gz [Regression Potential] * This is mostly a documentation correction, however if somebody still depends bluetooth started with Ubuntu 16.04+ by upstart (or possibly some kind of upstart compatibility in systemd, is that even possible?) he/she may end up with bluetooth not being started. This seems highly unlikely. [Other Info] * Original bug description: Support for config files has been dropped upstream in 2012 (however version shipped with Trusty still supports it), but the latest versions (including Xenial and Zesty) still mention it in the docs and in the legacy /etc/init/bluetooth.conf file. Additionally the /etc/init/bluetooth.conf don't seem necessary these days. In fact it has been dropped by Debian already. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1674680/+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 1674680] Re: Deprecated rfcomm.conf still mentioned
** Tags added: sts-sponsor-chiluk -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1674680 Title: Deprecated rfcomm.conf still mentioned Status in bluez package in Ubuntu: New Status in bluez source package in Xenial: New Status in bluez source package in Yakkety: New Bug description: [Impact] * The package contains misleading documentation mentioning the use of /etc/bluetooth/rfcomm.conf for rfcomm setup while the support for config file has been dropped after 14.04 release. I have directly received a question about it from a user mislead by the documentation. * Additionally deprecated -f option is still used in legacy upstart /etc/init/bluetooth.conf. Actually this does not seem longer required due to upstart being removed. [Test Case] * Install bluez. * Look for misleading rfcomm.conf mentions in /etc/init/bluetooth.conf, /usr/share/doc/bluez/README.Debian.gz [Regression Potential] * This is mostly a documentation correction, however if somebody still depends bluetooth started with Ubuntu 16.04+ by upstart (or possibly some kind of upstart compatibility in systemd, is that even possible?) he/she may end up with bluetooth not being started. This seems highly unlikely. [Other Info] * Original bug description: Support for config files has been dropped upstream in 2012 (however version shipped with Trusty still supports it), but the latest versions (including Xenial and Zesty) still mention it in the docs and in the legacy /etc/init/bluetooth.conf file. Additionally the /etc/init/bluetooth.conf don't seem necessary these days. In fact it has been dropped by Debian already. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1674680/+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 1664602] Re: Using an NVMe drive causes huge power drain
@Kai-Heng have you been able to make any progress on this? I think Tim is simply waiting on a git branch or git send-email submission to the kernel-team mailing list. -- 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/1664602 Title: Using an NVMe drive causes huge power drain Status in linux package in Ubuntu: Fix Committed Status in linux source package in Zesty: Fix Committed Bug description: PCIe NVMe drives are very common in new laptops. The Zesty's kernels (including latest 4.10 rc8 from CKT PPA) does not support APST (autonomous power state transitions). A patch does exist : http://lists.infradead.org/pipermail/linux-nvme/2017-February/008051.html https://github.com/damige/linux-nvme It seems that we cannot expect this before kernel 4.11. Additionally my laptop CPU does never go under PC3 power saving state, powertop says. I don't know if it's related. --- ApportVersion: 2.20.4-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: ft 1900 F pulseaudio CurrentDesktop: GNOME DistroRelease: Ubuntu 17.04 HibernationDevice: RESUME=UUID=a04b55bf-b1b6-464c-88ce-44b6adbbbc10 InstallationDate: Installed on 2016-12-12 (63 days ago) InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Alpha amd64 (20161211) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Dell Inc. Precision 7510 Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=fr_FR.UTF-8 SHELL=/bin/bash ProcFB: 0 nouveaufb 1 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.10.0-8-generic root=UUID=0d1f213e-73a9-4097-ae64-9cd963cfba23 ro quiet ProcVersionSignature: Ubuntu 4.10.0-8.10-generic 4.10.0-rc8 RelatedPackageVersions: linux-restricted-modules-4.10.0-8-generic N/A linux-backports-modules-4.10.0-8-generic N/A linux-firmware1.163 Tags: zesty Uname: Linux 4.10.0-8-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 12/22/2016 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.9.5 dmi.board.name: 0YH43H dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.9.5:bd12/22/2016:svnDellInc.:pnPrecision7510:pvr:rvnDellInc.:rn0YH43H:rvrA00:cvnDellInc.:ct9:cvr: dmi.product.name: Precision 7510 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664602/+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 1674680] Re: Deprecated rfcomm.conf still mentioned
** Also affects: bluez (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: bluez (Ubuntu Yakkety) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1674680 Title: Deprecated rfcomm.conf still mentioned Status in bluez package in Ubuntu: New Status in bluez source package in Xenial: New Status in bluez source package in Yakkety: New Bug description: Support for config files has been dropped upstream in 2012 (however version shipped with Trusty still supports it), but the latest versions (including Xenial and Zesty) still mention it in the docs and in the legacy /etc/init/bluetooth.conf file. Additionally the /etc/init/bluetooth.conf don't seem necessary these days. In fact it has been dropped by Debian already. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1674680/+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 1674763] [NEW] Warnings then GPF originating from nouveau under zesty
Public bug reported: unity-settings-[4857]: failed to turn the kbd backlight off: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface 'org.freedesktop.UPower.KbdBacklight' on object at path /org/freedesktop/UPower/KbdBacklight polkit-gnome-au[7926]: cannot open display: :0 kernel: [ 2607.528731] [ cut here ] kernel: [ 2607.528802] WARNING: CPU: 6 PID: 4317 at /build/linux-ZNEhaM/linux-4.10.0/drivers/gpu/drm/nouveau/nouveau_bo.c:137 nouveau_bo_del_ttm+0x7f/0x90 [nouveau] kernel: [ 2607.528803] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace sunrpc fscache snd_hda_codec_hdmi gpio_ich snd_hda_codec_realtek snd_hda_codec_generic coretemp snd_hda_intel snd_hda_codec snd_seq_midi snd_seq_midi_event snd_hda_core snd_hwdep kvm_intel snd_rawmidi snd_pcm kvm snd_seq irqbypass joydev input_leds intel_cstate snd_seq_device i7core_edac snd_timer serio_raw snd edac_core lpc_ich soundcore mei_me mei shpchp mac_hid ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear hid_generic usbhid hid nouveau mxm_wmi wmi i2c_algo_bit ttm drm_kms_helper kernel: [ 2607.528863] syscopyarea sysfillrect psmouse sysimgblt ahci e1000e fb_sys_fops libahci drm ptp pps_core pata_acpi fjes video kernel: [ 2607.528876] CPU: 6 PID: 4317 Comm: Xorg Not tainted 4.10.0-13-generic #15-Ubuntu kernel: [ 2607.528877] Hardware name: /DQ57TM, BIOS TMIBX10H.86A.0050.2011.1207.1134 12/07/2011 kernel: [ 2607.528878] Call Trace: kernel: [ 2607.528887] dump_stack+0x63/0x81 kernel: [ 2607.528890] __warn+0xcb/0xf0 kernel: [ 2607.528892] warn_slowpath_null+0x1d/0x20 kernel: [ 2607.528950] nouveau_bo_del_ttm+0x7f/0x90 [nouveau] kernel: [ 2607.528958] ttm_bo_release_list+0xcb/0x210 [ttm] kernel: [ 2607.528965] ttm_bo_release+0x19d/0x230 [ttm] kernel: [ 2607.528972] ttm_bo_unref+0x24/0x30 [ttm] kernel: [ 2607.529029] nouveau_gem_object_del+0x94/0xf0 [nouveau] kernel: [ 2607.529047] drm_gem_object_free+0x29/0x70 [drm] kernel: [ 2607.529062] drm_gem_object_unreference_unlocked+0x3a/0xa0 [drm] kernel: [ 2607.529077] drm_gem_object_handle_unreference_unlocked+0x65/0xb0 [drm] kernel: [ 2607.529093] drm_gem_object_release_handle+0x53/0x90 [drm] kernel: [ 2607.529095] idr_for_each+0xb0/0x110 kernel: [ 2607.529110] ? drm_gem_object_handle_unreference_unlocked+0xb0/0xb0 [drm] kernel: [ 2607.529168] ? nouveau_abi16_fini+0x50/0x70 [nouveau] kernel: [ 2607.529184] drm_gem_release+0x20/0x30 [drm] kernel: [ 2607.529199] drm_release+0x316/0x370 [drm] kernel: [ 2607.529202] __fput+0xe7/0x220 kernel: [ 2607.529205] fput+0xe/0x10 kernel: [ 2607.529207] task_work_run+0x80/0xa0 kernel: [ 2607.529210] do_exit+0x2ce/0xb10 kernel: [ 2607.529214] ? __do_page_fault+0x266/0x4e0 kernel: [ 2607.529216] do_group_exit+0x43/0xb0 kernel: [ 2607.529219] SyS_exit_group+0x14/0x20 kernel: [ 2607.529223] entry_SYSCALL_64_fastpath+0x1e/0xad kernel: [ 2607.529225] RIP: 0033:0x7f671d698b48 kernel: [ 2607.529226] RSP: 002b:7fff74c8cba8 EFLAGS: 0246 ORIG_RAX: 00e7 kernel: [ 2607.529229] RAX: ffda RBX: 55a1dc69e3b0 RCX: 7f671d698b48 kernel: [ 2607.529230] RDX: RSI: 003c RDI: kernel: [ 2607.529232] RBP: 7fff74c8cba0 R08: 00e7 R09: fc90 kernel: [ 2607.529233] R10: 7f671210a148 R11: 0246 R12: 7f6712109d90 kernel: [ 2607.529234] R13: 0044 R14: R15: 7fff74c8c8c0 kernel: [ 2607.529237] ---[ end trace 886311290d3f1a12 ]--- kernel: [ 2607.529322] [ cut here ] kernel: [ 2607.529322] [ cut here ] kernel: [ 2607.529383] WARNING: CPU: 6 PID: 4317 at /build/linux-ZNEhaM/linux-4.10.0/drivers/gpu/drm/nouveau/nouveau_bo.c:137 nouveau_bo_del_ttm+0x7f/0x90 [nouveau] kernel: [ 2607.529383] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace sunrpc fscache snd_hda_codec_hdmi gpio_ich snd_hda_codec_realtek snd_hda_codec_generic coretemp snd_hda_intel snd_hda_codec snd_seq_midi snd_seq_midi_event snd_hda_core snd_hwdep kvm_intel snd_rawmidi snd_pcm kvm snd_seq irqbypass joydev input_leds intel_cstate snd_seq_device i7core_edac snd_timer serio_raw snd edac_core lpc_ich soundcore mei_me mei shpchp mac_hid ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear hid_generic usbhid hid nouveau mxm_wmi wmi i2c_algo_bit ttm drm_kms_helper kernel: [ 2607.529431] syscopyarea sysfillrect psmouse sysimgblt ahci
[Kernel-packages] [Bug 1328088] Re: Kernel network namespace performance regression during rcu development on kernels above 3.8
@gnanasekarkas. Not that we know of.
--
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/1328088
Title:
Kernel network namespace performance regression during rcu development
on kernels above 3.8
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Trusty:
Fix Released
Status in linux source package in Utopic:
Fix Released
Bug description:
SRU Justification:
Impact: network namespace creation has performance regression since v3.5.
Fix: my analysis, lklm discussion, upstream patch
Testcase:
http://people.canonical.com/~inaddy/lp1328088/make_fake_routers.sh
http://people.canonical.com/~inaddy/lp1328088/parse.py
http://people.canonical.com/~inaddy/lp1328088/charts/250.html
http://people.canonical.com/~inaddy/lp1328088/charts/250-tag.html
Running make_fake_routers.sh 4000 and using parse.py you can check if
"fake routers" are being created in a good rate /sec (and you can
compare with all generated charts).
Original Description:
Please, follow this in:
http://people.canonical.com/~inaddy/lp1328088/. Same description on
daily-basis updated text.
--
It was brought to my attention that network namespace creation scalability
was affected during kernel development.
The following script was used for all the tests and charts generation:
http://people.canonical.com/~inaddy/lp1328088/make_fake_routers.sh
http://people.canonical.com/~inaddy/lp1328088/parse.py
I measured how many "fake routers" (above script) could be added per
second from 0 to 4000 created routers mark. Using this script and a
git bisect on kernel tree I was led to one specific commit causing
regression: #911af50 "rcu: Provide compile-time control for no-CBs
CPUs". Even Though this change was experimental at that point, it
introduced a performance scalability regression (explained below) that
still last and seems to be the default option for distributions
nowadays.
RCU related code looked like to be responsible for the problem. With
that, every commit from tag v3.8..master that changed any of this
files: "kernel/rcutree.c kernel/rcutree.h kernel/rcutree_plugin.h
include/trace/events/rcu.h include/linux/rcupdate.h" was tested. The
idea was to check performance regression during rcu development. In
the worst case, the regression not being related to rcu, I would still
have data to interpret the performance/scalability regression.
All text below this refer to 2 groups of charts, generated during the
study:
1) Kernel git tags from 3.8 to 3.14.
http://people.canonical.com/~inaddy/lp1328088/charts/250-tag.html
2) Kernel git commits for rcu development (111 commits).
http://people.canonical.com/~inaddy/lp1328088/charts/250.html
Since there was difference in results depending on how many cpus or
how the no-cb cpus were configured, 3 kernel config options were used
on every measure:
- CONFIG_RCU_NOCB_CPU (disabled): nocbno
- CONFIG_RCU_NOCB_CPU_ALL (enabled): nocball
- CONFIG_RCU_NOCB_CPU_NONE (enabled): nocbnone
Obs: For 1 cpu cases: nocbno, nocbnone, nocball behaves the same since
w/ only 1 cpu there is no no-cb cpu
After charts being generated it was clear that NOCB_CPU_ALL (4 cpus)
affected the "fake routers" creation process performance and this
regression continues up to upstream version. It was also clear that,
after commit #911af50, having more than 1 cpu does not improve
performance/scalability for netns, makes it worse.
#911af50
...
+#ifdef CONFIG_RCU_NOCB_CPU_ALL
+ pr_info("\tExperimental no-CBs for all CPUs\n");
+ cpumask_setall(rcu_nocb_mask);
+#endif /* #ifdef CONFIG_RCU_NOCB_CPU_ALL */
...
Comparing standing out points (see charts):
#81e5949 - good
#911af50 - bad
I was able to see that, from the script above, the following lines
causes major impact on netns scalability/performance:
1) ip netns add -> huge performance regression:
1 cpu: no regression
4 cpu: regression for NOCB_CPU_ALL
obs: regression from 250 netns/sec to 50 netns/sec
on 500 netns already created mark
2) ip netns exec -> some performance regression
1 cpu: no regression
4 cpu: regression for NOCB_CPU_ALL
obs: regression from 40 netns (+1 exec per netns
creation) to 20 netns/sec on 500 netns created
mark
# Assumption (to be confirmed)
rcu callbacks being offloaded to other cpus caused regression in
copy_net_ns<-created_new_namespaces or unshare(clone_newnet).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1328088/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https:/
[Kernel-packages] [Bug 1664602] Re: Using an NVMe drive causes huge power drain
@Tim, When I checked the backport it was not a clean cherry-pick. As you mentioned earlier there was some prerequisite patches that git pulled in. I did not continue investigating, but I guess there should only be a few. Either way the patches seem nvme @Kai-Heng Feng, please make sure you appropriately document and separate out patches that cleanly cherry-pick. Also please be careful for context patches that git pulls in to make the patch apply. -- 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/1664602 Title: Using an NVMe drive causes huge power drain Status in linux package in Ubuntu: Fix Released Status in linux source package in Zesty: Won't Fix Bug description: PCIe NVMe drives are very common in new laptops. The Zesty's kernels (including latest 4.10 rc8 from CKT PPA) does not support APST (autonomous power state transitions). A patch does exist : http://lists.infradead.org/pipermail/linux-nvme/2017-February/008051.html https://github.com/damige/linux-nvme It seems that we cannot expect this before kernel 4.11. Additionally my laptop CPU does never go under PC3 power saving state, powertop says. I don't know if it's related. --- ApportVersion: 2.20.4-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: ft 1900 F pulseaudio CurrentDesktop: GNOME DistroRelease: Ubuntu 17.04 HibernationDevice: RESUME=UUID=a04b55bf-b1b6-464c-88ce-44b6adbbbc10 InstallationDate: Installed on 2016-12-12 (63 days ago) InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Alpha amd64 (20161211) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Dell Inc. Precision 7510 Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=fr_FR.UTF-8 SHELL=/bin/bash ProcFB: 0 nouveaufb 1 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.10.0-8-generic root=UUID=0d1f213e-73a9-4097-ae64-9cd963cfba23 ro quiet ProcVersionSignature: Ubuntu 4.10.0-8.10-generic 4.10.0-rc8 RelatedPackageVersions: linux-restricted-modules-4.10.0-8-generic N/A linux-backports-modules-4.10.0-8-generic N/A linux-firmware1.163 Tags: zesty Uname: Linux 4.10.0-8-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 12/22/2016 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.9.5 dmi.board.name: 0YH43H dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.9.5:bd12/22/2016:svnDellInc.:pnPrecision7510:pvr:rvnDellInc.:rn0YH43H:rvrA00:cvnDellInc.:ct9:cvr: dmi.product.name: Precision 7510 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664602/+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 1664602] Re: Using an NVMe drive causes huge power drain
I can confirm Francois experience with my 950 pro. Although I saved one or two watts. It's a bit hard to tell. However my PC states were already reaching PC8 before this patch. -- 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/1664602 Title: Using an NVMe drive causes huge power drain Status in linux package in Ubuntu: Fix Released Status in linux source package in Zesty: Won't Fix Bug description: PCIe NVMe drives are very common in new laptops. The Zesty's kernels (including latest 4.10 rc8 from CKT PPA) does not support APST (autonomous power state transitions). A patch does exist : http://lists.infradead.org/pipermail/linux-nvme/2017-February/008051.html https://github.com/damige/linux-nvme It seems that we cannot expect this before kernel 4.11. Additionally my laptop CPU does never go under PC3 power saving state, powertop says. I don't know if it's related. --- ApportVersion: 2.20.4-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: ft 1900 F pulseaudio CurrentDesktop: GNOME DistroRelease: Ubuntu 17.04 HibernationDevice: RESUME=UUID=a04b55bf-b1b6-464c-88ce-44b6adbbbc10 InstallationDate: Installed on 2016-12-12 (63 days ago) InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Alpha amd64 (20161211) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Dell Inc. Precision 7510 Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=fr_FR.UTF-8 SHELL=/bin/bash ProcFB: 0 nouveaufb 1 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.10.0-8-generic root=UUID=0d1f213e-73a9-4097-ae64-9cd963cfba23 ro quiet ProcVersionSignature: Ubuntu 4.10.0-8.10-generic 4.10.0-rc8 RelatedPackageVersions: linux-restricted-modules-4.10.0-8-generic N/A linux-backports-modules-4.10.0-8-generic N/A linux-firmware1.163 Tags: zesty Uname: Linux 4.10.0-8-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 12/22/2016 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.9.5 dmi.board.name: 0YH43H dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.9.5:bd12/22/2016:svnDellInc.:pnPrecision7510:pvr:rvnDellInc.:rn0YH43H:rvrA00:cvnDellInc.:ct9:cvr: dmi.product.name: Precision 7510 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664602/+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 1639299] Re: acpi_pad consumes 100% of resources
** 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/1639299 Title: acpi_pad consumes 100% of resources Status in Nvidia: New Status in linux package in Ubuntu: New Bug description: acpi_pad will take up 100% of the CPU resources and slow the system to a crawl. 'rmmod acpi_pad' removes the offender and brings the system response back. PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 20765 root 20 0 0 0 0 R 100.0 0.0 5:07.99 xhpl 20879 root -2 0 0 0 0 R 100.0 0.0 7:12.40 acpi_pad/5 20887 root -2 0 0 0 0 R 100.0 0.0 6:57.72 acpi_pad/13 20891 root -2 0 0 0 0 R 100.0 0.0 7:05.74 acpi_pad/17 20874 root -2 0 0 0 0 R 100.0 0.0 7:15.16 acpi_pad/0 20875 root -2 0 0 0 0 R 100.0 0.0 7:14.76 acpi_pad/1 20876 root -2 0 0 0 0 R 100.0 0.0 7:13.54 acpi_pad/2 20877 root -2 0 0 0 0 R 100.0 0.0 7:13.54 acpi_pad/3 20880 root -2 0 0 0 0 R 100.0 0.0 7:11.44 acpi_pad/6 20881 root -2 0 0 0 0 R 100.0 0.0 7:11.17 acpi_pad/7 20882 root -2 0 0 0 0 R 100.0 0.0 7:05.42 acpi_pad/8 20883 root -2 0 0 0 0 R 100.0 0.0 7:10.80 acpi_pad/9 20884 root -2 0 0 0 0 R 100.0 0.0 7:09.50 acpi_pad/10 20885 root -2 0 0 0 0 R 100.0 0.0 7:09.66 acpi_pad/11 20888 root -2 0 0 0 0 R 100.0 0.0 7:07.30 acpi_pad/14 20889 root -2 0 0 0 0 R 100.0 0.0 7:07.37 acpi_pad/15 20890 root -2 0 0 0 0 R 100.0 0.0 7:05.50 acpi_pad/16 20892 root -2 0 0 0 0 R 100.0 0.0 7:04.40 acpi_pad/18 20893 root -2 0 0 0 0 R 100.0 0.0 7:04.21 acpi_pad/19 20894 root -2 0 0 0 0 R 100.0 0.0 7:03.70 acpi_pad/20 20895 root -2 0 0 0 0 R 100.0 0.0 7:03.63 acpi_pad/21 20896 root -2 0 0 0 0 R 100.0 0.0 7:01.61 acpi_pad/22 20897 root -2 0 0 0 0 R 100.0 0.0 7:01.66 acpi_pad/23 20898 root -2 0 0 0 0 R 100.0 0.0 7:00.80 acpi_pad/24 20899 root -2 0 0 0 0 R 100.0 0.0 7:00.81 acpi_pad/25 20901 root -2 0 0 0 0 R 100.0 0.0 6:58.79 acpi_pad/26 20902 root -2 0 0 0 0 R 100.0 0.0 6:58.96 acpi_pad/27 20903 root -2 0 0 0 0 R 100.0 0.0 6:57.82 acpi_pad/28 20904 root -2 0 0 0 0 R 100.0 0.0 6:57.83 acpi_pad/29 20906 root -2 0 0 0 0 R 100.0 0.0 6:55.54 acpi_pad/31 20886 root -2 0 0 0 0 R 99.7 0.0 7:08.80 acpi_pad/12 20878 root -2 0 0 0 0 R 98.4 0.0 7:12.20 acpi_pad/4 20905 root -2 0 0 0 0 R 98.4 0.0 6:55.85 acpi_pad/30 3049 newrelic 20 0 245800 8388 4724 S 22.3 0.0 0:14.74 nrsysmond 22126 root 20 0 19592 3876 2392 R 6.0 0.0 0:00.99 top 1441 root 39 19 0 0 0 S 3.4 0.0 3:05.47 kipmi0 20720 root 20 0 870276 13080 6208 S 1.6 0.0 0:01.50 collectd 8 root 20 0 0 0 0 S 0.9 0.0 0:03.19 rcu_sched 13 root rt 0 0 0 0 S 0.3 0.0 0:00.03 watchdog/0 This has been seen on the 4.2 and 4.4 kernels. I believe the LINPACK test suite was running in all cases this was seen. However, it occurs pretty infrequently, and I don't know how to reliably recreate the issue. It has only been seen on the DGX-1 Server, not on the DGX Station. I'm not sure if any other systems have seen it. Another data point which may or may not be relevant is that C-states and P-states are enabled. We can workaround this issue by blacklisting the acpi_pad module, or by using the acpi_pad.disable=1 kernel bootarg. What are the implications of disabling acpi_pad are? Googling "acpi_pad uses up all the resource" returns many hits where they all suggest to simply disable it. To manage notifications about this bug go to: https://bugs.launchpad.net/nvidia/+bug/1639299/+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 1579917] Re: Skylake processor never reaches low power states on X1 Carbon gen 4 with NVMe drive
@djao, sorry for the slow response. I hit pc8 briefly, but that's with most everything tuned, and running nothing. Lots of applications seem to be pretty power hungry for me. That's going to have to get tackled by each upstream project before we integrate solutions into the distro. @fthx. Welcome to the club. Did you try updating the IMEI firmware? -- 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/1579917 Title: Skylake processor never reaches low power states on X1 Carbon gen 4 with NVMe drive Status in linux package in Ubuntu: Invalid Bug description: Reproducer 1. Find a skylake machine. - in my case Lenovo x1 carbon gen 4. In my case with an NVME drive. 2. run powertop, and switch to idle stats tab 3. do nothing. *(as in let the machine idle till the cores regularly reach low power states. 4. Watch the watts fly. On my machine the package never gets into any power state other than PC2. Expected results: PC3-PC10 power states should all show some usage. I also tried the mainline build of 4.6-rc7 with no benefits. Public conversations about the issue https://mjg59.dreamwidth.org/42156.html https://mjg59.dreamwidth.org/41713.html As far as I can tell having the nvme drive is part of the overall problem here. Please keep this case to skylake + nvme. Skylake + sata appears to have a number of fixes in the 4.6 and newer kernels that enable some of the higher sleep states, but I have not tested with a sata drive. Those fixes as of testing 4.6-rc7 do not resolve this issue with users who have nvme drives. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-22-generic 4.4.0-22.39 ProcVersionSignature: Ubuntu 4.4.0-22.39-generic 4.4.8 Uname: Linux 4.4.0-22-generic x86_64 ApportVersion: 2.20.1-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: chiluk 3139 F pulseaudio CurrentDesktop: Unity Date: Mon May 9 15:55:03 2016 HibernationDevice: RESUME=UUID=4f4ea88e-642e-4be5-bdf0-bbc7f47f5628 InstallationDate: Installed on 2016-04-25 (14 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 04f2:b531 Chicony Electronics Co., Ltd Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: LENOVO 20FBCTO1WW ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-22-generic.efi.signed root=UUID=249f91bb-7789-41cc-9cc0-8ba25d7f55bb ro quiet splash pcie_aspm=force vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-4.4.0-22-generic N/A linux-backports-modules-4.4.0-22-generic N/A linux-firmware1.157 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/15/2016 dmi.bios.vendor: LENOVO dmi.bios.version: N1FET37W (1.11 ) dmi.board.asset.tag: Not Available dmi.board.name: 20FBCTO1WW dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN1FET37W(1.11):bd03/15/2016:svnLENOVO:pn20FBCTO1WW:pvrThinkPadX1Carbon4th:rvnLENOVO:rn20FBCTO1WW:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrNone: dmi.product.name: 20FBCTO1WW dmi.product.version: ThinkPad X1 Carbon 4th dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1579917/+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 1639202] Re: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter
** Changed in: initramfs-tools (Ubuntu) Status: New => Invalid ** Changed in: maas-images Status: New => Invalid -- 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/1639202 Title: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter Status in MAAS: Invalid Status in maas-images: Invalid Status in initramfs-tools package in Ubuntu: Invalid Status in linux package in Ubuntu: Invalid Bug description: After upgrade from MAAS 2.0 to MAAS 2.1: Cannot enlist/commission client machines via network boot (or pre- staging machine) when using usb-c network adapter D59GG (e.g. Precision 5510). This was working ok with MAAS 2.0. Using the Xenial 16.04 base image for enlist/commission (no minimum kernel set). Enlist/Commission/Deploy works fine with other laptop and desktop models which have a built in NIC. From an already deployed Precision 5510 system (16.04.1) I can see the following module is loaded when the usb-c adapter is connected (and working): $ lsmod usbnet45056 1 cdc_ether Errors received on client during enlisting with MAAS: no /run/net-bootif.conf lvmetad is not activated ...invalid path for logical volume. gave up waiting for root device common problems: boot args (cat /proc/cmdline) check rootdelay = (did system wait long enough) check root = (did the system wait for the right device?) missing modules (cat /proc/modules) ALERT! /dev/disk/by-path/ip-:3260-iscsi-iqn,2004.05.com.ubuntu:maas:ephemeral-ubuntu-amd64-generic-xenial-daily-lun-1 does not exist. Dropping to shell! usbcore: registered new interface driver usbhid usbhid: USB HID core driver - cat /proc/cmdline shows mac address that of usb-c network adapter. - cat /proc/modules includes “usbnet 45056 cdc_ether, Live 0xc009c000” - cat /proc/modules | grep usb … includes “ usbnet 45056 and usbhid 49152” I've tried enlisting with older boot image and different kernel versions (14.04 and 16.04 with ga-16.04, hwe-16.04 set) but get the same problem. It seems like the usb-c network adapter isn't loading properly or maybe just not quickly enough? Please let me know if you require any more info. I can provide info from /var/log/maas/* and dpkg -l '*maas*'|cat if need be. To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1639202/+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 1639202] Re: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter
So apparently this is a feature of the dell-branded usb-c devices. Please see the knowledge base. http://www.dell.com/support/article/us/en/04/SLN301147 I've heard back from our contacts at dell, and the issue you are seeing is apparently resolved via a firmware update. -- 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/1639202 Title: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter Status in MAAS: Invalid Status in maas-images: New Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: Invalid Bug description: After upgrade from MAAS 2.0 to MAAS 2.1: Cannot enlist/commission client machines via network boot (or pre- staging machine) when using usb-c network adapter D59GG (e.g. Precision 5510). This was working ok with MAAS 2.0. Using the Xenial 16.04 base image for enlist/commission (no minimum kernel set). Enlist/Commission/Deploy works fine with other laptop and desktop models which have a built in NIC. From an already deployed Precision 5510 system (16.04.1) I can see the following module is loaded when the usb-c adapter is connected (and working): $ lsmod usbnet45056 1 cdc_ether Errors received on client during enlisting with MAAS: no /run/net-bootif.conf lvmetad is not activated ...invalid path for logical volume. gave up waiting for root device common problems: boot args (cat /proc/cmdline) check rootdelay = (did system wait long enough) check root = (did the system wait for the right device?) missing modules (cat /proc/modules) ALERT! /dev/disk/by-path/ip-:3260-iscsi-iqn,2004.05.com.ubuntu:maas:ephemeral-ubuntu-amd64-generic-xenial-daily-lun-1 does not exist. Dropping to shell! usbcore: registered new interface driver usbhid usbhid: USB HID core driver - cat /proc/cmdline shows mac address that of usb-c network adapter. - cat /proc/modules includes “usbnet 45056 cdc_ether, Live 0xc009c000” - cat /proc/modules | grep usb … includes “ usbnet 45056 and usbhid 49152” I've tried enlisting with older boot image and different kernel versions (14.04 and 16.04 with ga-16.04, hwe-16.04 set) but get the same problem. It seems like the usb-c network adapter isn't loading properly or maybe just not quickly enough? Please let me know if you require any more info. I can provide info from /var/log/maas/* and dpkg -l '*maas*'|cat if need be. To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1639202/+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 1639202] Re: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter
Another thought is that the pxe firmware of the usb-c device was missed in the rebranding process by dell. This is actually quite likely in my opinion. Either way we need to engage Dell in order to remedy this. -- 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/1639202 Title: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter Status in MAAS: Invalid Status in maas-images: New Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: Invalid Bug description: After upgrade from MAAS 2.0 to MAAS 2.1: Cannot enlist/commission client machines via network boot (or pre- staging machine) when using usb-c network adapter D59GG (e.g. Precision 5510). This was working ok with MAAS 2.0. Using the Xenial 16.04 base image for enlist/commission (no minimum kernel set). Enlist/Commission/Deploy works fine with other laptop and desktop models which have a built in NIC. From an already deployed Precision 5510 system (16.04.1) I can see the following module is loaded when the usb-c adapter is connected (and working): $ lsmod usbnet45056 1 cdc_ether Errors received on client during enlisting with MAAS: no /run/net-bootif.conf lvmetad is not activated ...invalid path for logical volume. gave up waiting for root device common problems: boot args (cat /proc/cmdline) check rootdelay = (did system wait long enough) check root = (did the system wait for the right device?) missing modules (cat /proc/modules) ALERT! /dev/disk/by-path/ip-:3260-iscsi-iqn,2004.05.com.ubuntu:maas:ephemeral-ubuntu-amd64-generic-xenial-daily-lun-1 does not exist. Dropping to shell! usbcore: registered new interface driver usbhid usbhid: USB HID core driver - cat /proc/cmdline shows mac address that of usb-c network adapter. - cat /proc/modules includes “usbnet 45056 cdc_ether, Live 0xc009c000” - cat /proc/modules | grep usb … includes “ usbnet 45056 and usbhid 49152” I've tried enlisting with older boot image and different kernel versions (14.04 and 16.04 with ga-16.04, hwe-16.04 set) but get the same problem. It seems like the usb-c network adapter isn't loading properly or maybe just not quickly enough? Please let me know if you require any more info. I can provide info from /var/log/maas/* and dpkg -l '*maas*'|cat if need be. To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1639202/+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 1639202] Re: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter
Do you know where the 9c-eb-e8-3c-52-cc originates from? There is nothing we can do so long as the request to maas originates from the 9c- eb-e8-3c-52-cc mac address. If the firmware is somehow masking the actual mac address with the above then that needs to be fixed in the firmware, or via a firmware setting. Please attempt to figure out where the 9c-eb-e8-3c-52-cc is. If it helps a mac search on 9c-eb-e8 yeilds: BizLink (Kunshan) Co. Ltd. A mac search of 84-7b-eb yeilds Dell Inc. I suspect they are really the same device. I have a feeling the usb-c adapter or docking station you are using is really just Bizlink device that Dell has rebranded. This really looks like a firmware bug, where the firmware uses the non- rebranded mac of the device for pxe while in efi, and the rebranded mac address in the OS after boot. Have you tried updating the firmware on your machine, and possibly also the firmware of the usb-c device? Thanks, Dave Chiluk -- 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/1639202 Title: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter Status in MAAS: Invalid Status in maas-images: New Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: Invalid Bug description: After upgrade from MAAS 2.0 to MAAS 2.1: Cannot enlist/commission client machines via network boot (or pre- staging machine) when using usb-c network adapter D59GG (e.g. Precision 5510). This was working ok with MAAS 2.0. Using the Xenial 16.04 base image for enlist/commission (no minimum kernel set). Enlist/Commission/Deploy works fine with other laptop and desktop models which have a built in NIC. From an already deployed Precision 5510 system (16.04.1) I can see the following module is loaded when the usb-c adapter is connected (and working): $ lsmod usbnet45056 1 cdc_ether Errors received on client during enlisting with MAAS: no /run/net-bootif.conf lvmetad is not activated ...invalid path for logical volume. gave up waiting for root device common problems: boot args (cat /proc/cmdline) check rootdelay = (did system wait long enough) check root = (did the system wait for the right device?) missing modules (cat /proc/modules) ALERT! /dev/disk/by-path/ip-:3260-iscsi-iqn,2004.05.com.ubuntu:maas:ephemeral-ubuntu-amd64-generic-xenial-daily-lun-1 does not exist. Dropping to shell! usbcore: registered new interface driver usbhid usbhid: USB HID core driver - cat /proc/cmdline shows mac address that of usb-c network adapter. - cat /proc/modules includes “usbnet 45056 cdc_ether, Live 0xc009c000” - cat /proc/modules | grep usb … includes “ usbnet 45056 and usbhid 49152” I've tried enlisting with older boot image and different kernel versions (14.04 and 16.04 with ga-16.04, hwe-16.04 set) but get the same problem. It seems like the usb-c network adapter isn't loading properly or maybe just not quickly enough? Please let me know if you require any more info. I can provide info from /var/log/maas/* and dpkg -l '*maas*'|cat if need be. To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1639202/+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 1639202] Re: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter
Alright so the problem at present appears to be that the machine is pxe booting off of a nic with a mac address that is not showing up after the kernel boots. The way the boot works is the bios/efi launches a pxe network stack. This typically makes a dhcp request. The DHCP server responds with an IP address, and the address of the PXE/TFTP server *(in this case the maas server). The network stack firmware on the client then requests the kernel, initramfs and kernel arguments from the PXE server. The bios/efi pxe network stack then downloads this, and executes the kernel. One of the arguments maas is responding with BOOTIF=01-9c- eb-e8-3c-52-cc. This means the original pxe request originates from this mac address. When the initramfs starts it runs a script function called configure_networking that attempts to set up the BOOTIF=01-9c- eb-e8-3c-52-cc NIC, but it doesn't appear to exist to the OS. This could mean a few things. - The NIC doing the initial pxe request is different than the usb-c one. Is there a chance that there's a wireless nic that has a pxe stack that you've configured? I know some newer machines are able to pxe boot off of their network cards so this would be useful to check. - The mac address is changing between the pxe request and the OS boot. - IPv6 is in the mix. Are you attempting to boot via ipv6? - The PXE server is responding with the incorrect mac address in BOOTIF. The last two can be checked by looking at /var/log/rackd.log on your maas server. You should be able to grep for 01-9c-eb-e8-3c-52-cc or 01-84-7b-eb-55-c1-95 in the rackd.log to see which nic is making the pxe request. If 01-9c-eb-e8-3c-52-cc shows up in the rackd.log then it's pretty definitive that the issue is booting using a nic with that mac somehow. Please check the above and let me know what you discover. Thanks, Dave. -- 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/1639202 Title: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter Status in MAAS: Invalid Status in maas-images: New Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: Invalid Bug description: After upgrade from MAAS 2.0 to MAAS 2.1: Cannot enlist/commission client machines via network boot (or pre- staging machine) when using usb-c network adapter D59GG (e.g. Precision 5510). This was working ok with MAAS 2.0. Using the Xenial 16.04 base image for enlist/commission (no minimum kernel set). Enlist/Commission/Deploy works fine with other laptop and desktop models which have a built in NIC. From an already deployed Precision 5510 system (16.04.1) I can see the following module is loaded when the usb-c adapter is connected (and working): $ lsmod usbnet45056 1 cdc_ether Errors received on client during enlisting with MAAS: no /run/net-bootif.conf lvmetad is not activated ...invalid path for logical volume. gave up waiting for root device common problems: boot args (cat /proc/cmdline) check rootdelay = (did system wait long enough) check root = (did the system wait for the right device?) missing modules (cat /proc/modules) ALERT! /dev/disk/by-path/ip-:3260-iscsi-iqn,2004.05.com.ubuntu:maas:ephemeral-ubuntu-amd64-generic-xenial-daily-lun-1 does not exist. Dropping to shell! usbcore: registered new interface driver usbhid usbhid: USB HID core driver - cat /proc/cmdline shows mac address that of usb-c network adapter. - cat /proc/modules includes “usbnet 45056 cdc_ether, Live 0xc009c000” - cat /proc/modules | grep usb … includes “ usbnet 45056 and usbhid 49152” I've tried enlisting with older boot image and different kernel versions (14.04 and 16.04 with ga-16.04, hwe-16.04 set) but get the same problem. It seems like the usb-c network adapter isn't loading properly or maybe just not quickly enough? Please let me know if you require any more info. I can provide info from /var/log/maas/* and dpkg -l '*maas*'|cat if need be. To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1639202/+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 1639202] Re: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter
One of my collegues informed me that maas 2.1 is meant to use https://images.maas.io/ephemeral-v3/daily/ Instead of the ephemeral-v2 images. -- 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/1639202 Title: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter Status in MAAS: Invalid Status in maas-images: New Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: Invalid Bug description: After upgrade from MAAS 2.0 to MAAS 2.1: Cannot enlist/commission client machines via network boot (or pre- staging machine) when using usb-c network adapter D59GG (e.g. Precision 5510). This was working ok with MAAS 2.0. Using the Xenial 16.04 base image for enlist/commission (no minimum kernel set). Enlist/Commission/Deploy works fine with other laptop and desktop models which have a built in NIC. From an already deployed Precision 5510 system (16.04.1) I can see the following module is loaded when the usb-c adapter is connected (and working): $ lsmod usbnet45056 1 cdc_ether Errors received on client during enlisting with MAAS: no /run/net-bootif.conf lvmetad is not activated ...invalid path for logical volume. gave up waiting for root device common problems: boot args (cat /proc/cmdline) check rootdelay = (did system wait long enough) check root = (did the system wait for the right device?) missing modules (cat /proc/modules) ALERT! /dev/disk/by-path/ip-:3260-iscsi-iqn,2004.05.com.ubuntu:maas:ephemeral-ubuntu-amd64-generic-xenial-daily-lun-1 does not exist. Dropping to shell! usbcore: registered new interface driver usbhid usbhid: USB HID core driver - cat /proc/cmdline shows mac address that of usb-c network adapter. - cat /proc/modules includes “usbnet 45056 cdc_ether, Live 0xc009c000” - cat /proc/modules | grep usb … includes “ usbnet 45056 and usbhid 49152” I've tried enlisting with older boot image and different kernel versions (14.04 and 16.04 with ga-16.04, hwe-16.04 set) but get the same problem. It seems like the usb-c network adapter isn't loading properly or maybe just not quickly enough? Please let me know if you require any more info. I can provide info from /var/log/maas/* and dpkg -l '*maas*'|cat if need be. To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1639202/+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 1639202] Re: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter
1. So this indicates to me that the kernel is unable to control the usb device. When you mentioned earlier that you were able to investigate the usb-c device with a 16.04.1 machine, what exact kernel version was that machine running. uname -a output should be sufficient. 2. Can you similarly provide the exact kernel version that you are using during commissioning, when dropped to shell? 3. Were you able to utilize the device under this kernel or did it simply load the kernel driver there as well? I.e. do you see a device for the usb device in /sys/class/net/? 4. Also can you please provide the lsusb -vv output from that machine as well. I'd like to look up the device id's against the cdc_ether driver to see if the device id was added to one of the later 4.4 kernels. 5. Also are you using stable images or daily images. If you haven't done so already can you enable the daily images, and check using those? Instructions are available here http://maas.io/docs/en/installconfig-images The images I'm referring to are available here https://images.maas.io/ephemeral-v2/daily/ Thank you, -- 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/1639202 Title: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter Status in MAAS: Invalid Status in maas-images: New Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: Invalid Bug description: After upgrade from MAAS 2.0 to MAAS 2.1: Cannot enlist/commission client machines via network boot (or pre- staging machine) when using usb-c network adapter D59GG (e.g. Precision 5510). This was working ok with MAAS 2.0. Using the Xenial 16.04 base image for enlist/commission (no minimum kernel set). Enlist/Commission/Deploy works fine with other laptop and desktop models which have a built in NIC. From an already deployed Precision 5510 system (16.04.1) I can see the following module is loaded when the usb-c adapter is connected (and working): $ lsmod usbnet45056 1 cdc_ether Errors received on client during enlisting with MAAS: no /run/net-bootif.conf lvmetad is not activated ...invalid path for logical volume. gave up waiting for root device common problems: boot args (cat /proc/cmdline) check rootdelay = (did system wait long enough) check root = (did the system wait for the right device?) missing modules (cat /proc/modules) ALERT! /dev/disk/by-path/ip-:3260-iscsi-iqn,2004.05.com.ubuntu:maas:ephemeral-ubuntu-amd64-generic-xenial-daily-lun-1 does not exist. Dropping to shell! usbcore: registered new interface driver usbhid usbhid: USB HID core driver - cat /proc/cmdline shows mac address that of usb-c network adapter. - cat /proc/modules includes “usbnet 45056 cdc_ether, Live 0xc009c000” - cat /proc/modules | grep usb … includes “ usbnet 45056 and usbhid 49152” I've tried enlisting with older boot image and different kernel versions (14.04 and 16.04 with ga-16.04, hwe-16.04 set) but get the same problem. It seems like the usb-c network adapter isn't loading properly or maybe just not quickly enough? Please let me know if you require any more info. I can provide info from /var/log/maas/* and dpkg -l '*maas*'|cat if need be. To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1639202/+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 1639202] Re: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter
If the device is not being detected I have a feeling there may be something going wrong with udev. -- 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/1639202 Title: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter Status in MAAS: Invalid Status in maas-images: New Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: Invalid Bug description: After upgrade from MAAS 2.0 to MAAS 2.1: Cannot enlist/commission client machines via network boot (or pre- staging machine) when using usb-c network adapter D59GG (e.g. Precision 5510). This was working ok with MAAS 2.0. Using the Xenial 16.04 base image for enlist/commission (no minimum kernel set). Enlist/Commission/Deploy works fine with other laptop and desktop models which have a built in NIC. From an already deployed Precision 5510 system (16.04.1) I can see the following module is loaded when the usb-c adapter is connected (and working): $ lsmod usbnet45056 1 cdc_ether Errors received on client during enlisting with MAAS: no /run/net-bootif.conf lvmetad is not activated ...invalid path for logical volume. gave up waiting for root device common problems: boot args (cat /proc/cmdline) check rootdelay = (did system wait long enough) check root = (did the system wait for the right device?) missing modules (cat /proc/modules) ALERT! /dev/disk/by-path/ip-:3260-iscsi-iqn,2004.05.com.ubuntu:maas:ephemeral-ubuntu-amd64-generic-xenial-daily-lun-1 does not exist. Dropping to shell! usbcore: registered new interface driver usbhid usbhid: USB HID core driver - cat /proc/cmdline shows mac address that of usb-c network adapter. - cat /proc/modules includes “usbnet 45056 cdc_ether, Live 0xc009c000” - cat /proc/modules | grep usb … includes “ usbnet 45056 and usbhid 49152” I've tried enlisting with older boot image and different kernel versions (14.04 and 16.04 with ga-16.04, hwe-16.04 set) but get the same problem. It seems like the usb-c network adapter isn't loading properly or maybe just not quickly enough? Please let me know if you require any more info. I can provide info from /var/log/maas/* and dpkg -l '*maas*'|cat if need be. To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1639202/+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 1639202] Re: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter
>From the initramfs shell can you provide me the output for ls -la /sys/class/net/* and cat /sys/class/net/*/address I have a feeling you'll only see lo and enx847beb55c195. Specifially I'm looking for the device name that matches your BOOTIF mac address. However if it's showing up please attempt to run $ ipconfig -t 100 Then see if the nic comes up from there with ip a. -- 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/1639202 Title: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter Status in MAAS: Invalid Status in maas-images: New Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: Invalid Bug description: After upgrade from MAAS 2.0 to MAAS 2.1: Cannot enlist/commission client machines via network boot (or pre- staging machine) when using usb-c network adapter D59GG (e.g. Precision 5510). This was working ok with MAAS 2.0. Using the Xenial 16.04 base image for enlist/commission (no minimum kernel set). Enlist/Commission/Deploy works fine with other laptop and desktop models which have a built in NIC. From an already deployed Precision 5510 system (16.04.1) I can see the following module is loaded when the usb-c adapter is connected (and working): $ lsmod usbnet45056 1 cdc_ether Errors received on client during enlisting with MAAS: no /run/net-bootif.conf lvmetad is not activated ...invalid path for logical volume. gave up waiting for root device common problems: boot args (cat /proc/cmdline) check rootdelay = (did system wait long enough) check root = (did the system wait for the right device?) missing modules (cat /proc/modules) ALERT! /dev/disk/by-path/ip-:3260-iscsi-iqn,2004.05.com.ubuntu:maas:ephemeral-ubuntu-amd64-generic-xenial-daily-lun-1 does not exist. Dropping to shell! usbcore: registered new interface driver usbhid usbhid: USB HID core driver - cat /proc/cmdline shows mac address that of usb-c network adapter. - cat /proc/modules includes “usbnet 45056 cdc_ether, Live 0xc009c000” - cat /proc/modules | grep usb … includes “ usbnet 45056 and usbhid 49152” I've tried enlisting with older boot image and different kernel versions (14.04 and 16.04 with ga-16.04, hwe-16.04 set) but get the same problem. It seems like the usb-c network adapter isn't loading properly or maybe just not quickly enough? Please let me know if you require any more info. I can provide info from /var/log/maas/* and dpkg -l '*maas*'|cat if need be. To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1639202/+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 1639202] Re: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter
So from the best I can determine it looks like configure_networking out of scripts/functions of the initramfs is failing to properly bring up the network device. I'm going through the process now to figure out what logic might actually be stopping it from functioning. I'll let you know more when I have something more concrete. -- 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/1639202 Title: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter Status in MAAS: Invalid Status in maas-images: New Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: Invalid Bug description: After upgrade from MAAS 2.0 to MAAS 2.1: Cannot enlist/commission client machines via network boot (or pre- staging machine) when using usb-c network adapter D59GG (e.g. Precision 5510). This was working ok with MAAS 2.0. Using the Xenial 16.04 base image for enlist/commission (no minimum kernel set). Enlist/Commission/Deploy works fine with other laptop and desktop models which have a built in NIC. From an already deployed Precision 5510 system (16.04.1) I can see the following module is loaded when the usb-c adapter is connected (and working): $ lsmod usbnet45056 1 cdc_ether Errors received on client during enlisting with MAAS: no /run/net-bootif.conf lvmetad is not activated ...invalid path for logical volume. gave up waiting for root device common problems: boot args (cat /proc/cmdline) check rootdelay = (did system wait long enough) check root = (did the system wait for the right device?) missing modules (cat /proc/modules) ALERT! /dev/disk/by-path/ip-:3260-iscsi-iqn,2004.05.com.ubuntu:maas:ephemeral-ubuntu-amd64-generic-xenial-daily-lun-1 does not exist. Dropping to shell! usbcore: registered new interface driver usbhid usbhid: USB HID core driver - cat /proc/cmdline shows mac address that of usb-c network adapter. - cat /proc/modules includes “usbnet 45056 cdc_ether, Live 0xc009c000” - cat /proc/modules | grep usb … includes “ usbnet 45056 and usbhid 49152” I've tried enlisting with older boot image and different kernel versions (14.04 and 16.04 with ga-16.04, hwe-16.04 set) but get the same problem. It seems like the usb-c network adapter isn't loading properly or maybe just not quickly enough? Please let me know if you require any more info. I can provide info from /var/log/maas/* and dpkg -l '*maas*'|cat if need be. To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1639202/+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 1639202] Re: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter
@Richard Lovell
Can you please provide me the console log messages that exist above the "no
/run/net-bootif.conf"?
Additionally can I get the output of following commands from the laptop after
the message "Dropping to shell!"
- ip a # I'm not sure if this available, but ifconfig or similar would be
helpful. Basically I need the name of the nic as discovered. I have a feeling
that the initramfs is not correctly checking for this name when it attempts to
bring up the interfaces.
- lsmod
- cat /proc/cmdline
More commands may be necessary after I have this output and am able to
investigate the initramfs.
Thanks
** Changed in: maas
Status: Incomplete => Invalid
** Also affects: initramfs-tools (Ubuntu)
Importance: Undecided
Status: New
** Changed in: initramfs-tools (Ubuntu)
Assignee: (unassigned) => Dave Chiluk (chiluk)
--
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/1639202
Title:
Cannot enlist/commission machines in MAAS 2.1 with usb network adapter
Status in MAAS:
Invalid
Status in maas-images:
New
Status in initramfs-tools package in Ubuntu:
New
Status in linux package in Ubuntu:
Invalid
Bug description:
After upgrade from MAAS 2.0 to MAAS 2.1:
Cannot enlist/commission client machines via network boot (or pre-
staging machine) when using usb-c network adapter D59GG (e.g.
Precision 5510). This was working ok with MAAS 2.0.
Using the Xenial 16.04 base image for enlist/commission (no minimum
kernel set).
Enlist/Commission/Deploy works fine with other laptop and desktop
models which have a built in NIC.
From an already deployed Precision 5510 system (16.04.1) I can see the
following module is loaded when the usb-c adapter is connected (and
working):
$ lsmod
usbnet45056 1 cdc_ether
Errors received on client during enlisting with MAAS:
no /run/net-bootif.conf
lvmetad is not activated
...invalid path for logical volume.
gave up waiting for root device
common problems: boot args (cat /proc/cmdline)
check rootdelay = (did system wait long enough)
check root = (did the system wait for the right device?)
missing modules (cat /proc/modules)
ALERT!
/dev/disk/by-path/ip-:3260-iscsi-iqn,2004.05.com.ubuntu:maas:ephemeral-ubuntu-amd64-generic-xenial-daily-lun-1
does not exist. Dropping to shell!
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
- cat /proc/cmdline shows mac address that of usb-c network adapter.
- cat /proc/modules includes “usbnet 45056 cdc_ether, Live 0xc009c000”
- cat /proc/modules | grep usb … includes “ usbnet 45056 and usbhid 49152”
I've tried enlisting with older boot image and different kernel versions
(14.04 and 16.04 with ga-16.04, hwe-16.04 set) but get the same problem.
It seems like the usb-c network adapter isn't loading properly or
maybe just not quickly enough?
Please let me know if you require any more info. I can provide info
from /var/log/maas/* and dpkg -l '*maas*'|cat if need be.
To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1639202/+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 1639202] Re: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter
I just checked the maas daily images, and both the 4.4.0-45 xenial and 4.8.0-27 yakkety initrd contain the cdc_ether kernel drivers. I also checked the 20160310 maas image that contains the 4.4.0-11-generic kernel, and it contains the drivers as well. So I now suspect that the initramfs is not correctly configuring the network adapter. -- 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/1639202 Title: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter Status in MAAS: Invalid Status in maas-images: New Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: Invalid Bug description: After upgrade from MAAS 2.0 to MAAS 2.1: Cannot enlist/commission client machines via network boot (or pre- staging machine) when using usb-c network adapter D59GG (e.g. Precision 5510). This was working ok with MAAS 2.0. Using the Xenial 16.04 base image for enlist/commission (no minimum kernel set). Enlist/Commission/Deploy works fine with other laptop and desktop models which have a built in NIC. From an already deployed Precision 5510 system (16.04.1) I can see the following module is loaded when the usb-c adapter is connected (and working): $ lsmod usbnet45056 1 cdc_ether Errors received on client during enlisting with MAAS: no /run/net-bootif.conf lvmetad is not activated ...invalid path for logical volume. gave up waiting for root device common problems: boot args (cat /proc/cmdline) check rootdelay = (did system wait long enough) check root = (did the system wait for the right device?) missing modules (cat /proc/modules) ALERT! /dev/disk/by-path/ip-:3260-iscsi-iqn,2004.05.com.ubuntu:maas:ephemeral-ubuntu-amd64-generic-xenial-daily-lun-1 does not exist. Dropping to shell! usbcore: registered new interface driver usbhid usbhid: USB HID core driver - cat /proc/cmdline shows mac address that of usb-c network adapter. - cat /proc/modules includes “usbnet 45056 cdc_ether, Live 0xc009c000” - cat /proc/modules | grep usb … includes “ usbnet 45056 and usbhid 49152” I've tried enlisting with older boot image and different kernel versions (14.04 and 16.04 with ga-16.04, hwe-16.04 set) but get the same problem. It seems like the usb-c network adapter isn't loading properly or maybe just not quickly enough? Please let me know if you require any more info. I can provide info from /var/log/maas/* and dpkg -l '*maas*'|cat if need be. To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1639202/+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 1639202] Re: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter
Please ignore the comment from brad-figg as the above comment originated from a bot. That being said, I've had a bit of an opportunity to research this. Initramfs-tools is responsible for updating the initramfs and including modules in the initramfs. Unfortunately I don't think that adding usbnet and cdc_ether to the default initramfs produced by the distro is the correct course of action on this case. That being said, it may be possible to create the maas images with all network modules in it as that would make more sense, in my opinion. I guess this is why Andre originally opened this against maas-images. -- 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/1639202 Title: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter Status in MAAS: Incomplete Status in maas-images: New Status in linux package in Ubuntu: Invalid Bug description: After upgrade from MAAS 2.0 to MAAS 2.1: Cannot enlist/commission client machines via network boot (or pre- staging machine) when using usb-c network adapter D59GG (e.g. Precision 5510). This was working ok with MAAS 2.0. Using the Xenial 16.04 base image for enlist/commission (no minimum kernel set). Enlist/Commission/Deploy works fine with other laptop and desktop models which have a built in NIC. From an already deployed Precision 5510 system (16.04.1) I can see the following module is loaded when the usb-c adapter is connected (and working): $ lsmod usbnet45056 1 cdc_ether Errors received on client during enlisting with MAAS: no /run/net-bootif.conf lvmetad is not activated ...invalid path for logical volume. gave up waiting for root device common problems: boot args (cat /proc/cmdline) check rootdelay = (did system wait long enough) check root = (did the system wait for the right device?) missing modules (cat /proc/modules) ALERT! /dev/disk/by-path/ip-:3260-iscsi-iqn,2004.05.com.ubuntu:maas:ephemeral-ubuntu-amd64-generic-xenial-daily-lun-1 does not exist. Dropping to shell! usbcore: registered new interface driver usbhid usbhid: USB HID core driver - cat /proc/cmdline shows mac address that of usb-c network adapter. - cat /proc/modules includes “usbnet 45056 cdc_ether, Live 0xc009c000” - cat /proc/modules | grep usb … includes “ usbnet 45056 and usbhid 49152” I've tried enlisting with older boot image and different kernel versions (14.04 and 16.04 with ga-16.04, hwe-16.04 set) but get the same problem. It seems like the usb-c network adapter isn't loading properly or maybe just not quickly enough? Please let me know if you require any more info. I can provide info from /var/log/maas/* and dpkg -l '*maas*'|cat if need be. To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1639202/+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 1639202] Re: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter
** Changed in: linux (Ubuntu) Status: Incomplete => Invalid -- 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/1639202 Title: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter Status in MAAS: Incomplete Status in maas-images: New Status in linux package in Ubuntu: Invalid Bug description: After upgrade from MAAS 2.0 to MAAS 2.1: Cannot enlist/commission client machines via network boot (or pre- staging machine) when using usb-c network adapter D59GG (e.g. Precision 5510). This was working ok with MAAS 2.0. Using the Xenial 16.04 base image for enlist/commission (no minimum kernel set). Enlist/Commission/Deploy works fine with other laptop and desktop models which have a built in NIC. From an already deployed Precision 5510 system (16.04.1) I can see the following module is loaded when the usb-c adapter is connected (and working): $ lsmod usbnet45056 1 cdc_ether Errors received on client during enlisting with MAAS: no /run/net-bootif.conf lvmetad is not activated ...invalid path for logical volume. gave up waiting for root device common problems: boot args (cat /proc/cmdline) check rootdelay = (did system wait long enough) check root = (did the system wait for the right device?) missing modules (cat /proc/modules) ALERT! /dev/disk/by-path/ip-:3260-iscsi-iqn,2004.05.com.ubuntu:maas:ephemeral-ubuntu-amd64-generic-xenial-daily-lun-1 does not exist. Dropping to shell! usbcore: registered new interface driver usbhid usbhid: USB HID core driver - cat /proc/cmdline shows mac address that of usb-c network adapter. - cat /proc/modules includes “usbnet 45056 cdc_ether, Live 0xc009c000” - cat /proc/modules | grep usb … includes “ usbnet 45056 and usbhid 49152” I've tried enlisting with older boot image and different kernel versions (14.04 and 16.04 with ga-16.04, hwe-16.04 set) but get the same problem. It seems like the usb-c network adapter isn't loading properly or maybe just not quickly enough? Please let me know if you require any more info. I can provide info from /var/log/maas/* and dpkg -l '*maas*'|cat if need be. To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1639202/+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 1639202] Re: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter
I'm adding the kernel to this, as I'm fairly certain the kernel is responsible for what modules are built into the default initramfs'. In this case it looks like cdc_ether and usbnet need to be added into the initramfs in order to solve a case like this. I'm not sure if this should be done in the kernel for all installations, or if it should be done via only maas-images ** 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/1639202 Title: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter Status in MAAS: Incomplete Status in maas-images: New Status in linux package in Ubuntu: New Bug description: After upgrade from MAAS 2.0 to MAAS 2.1: Cannot enlist/commission client machines via network boot (or pre- staging machine) when using usb-c network adapter D59GG (e.g. Precision 5510). This was working ok with MAAS 2.0. Using the Xenial 16.04 base image for enlist/commission (no minimum kernel set). Enlist/Commission/Deploy works fine with other laptop and desktop models which have a built in NIC. From an already deployed Precision 5510 system (16.04.1) I can see the following module is loaded when the usb-c adapter is connected (and working): $ lsmod usbnet45056 1 cdc_ether Errors received on client during enlisting with MAAS: no /run/net-bootif.conf lvmetad is not activated ...invalid path for logical volume. gave up waiting for root device common problems: boot args (cat /proc/cmdline) check rootdelay = (did system wait long enough) check root = (did the system wait for the right device?) missing modules (cat /proc/modules) ALERT! /dev/disk/by-path/ip-:3260-iscsi-iqn,2004.05.com.ubuntu:maas:ephemeral-ubuntu-amd64-generic-xenial-daily-lun-1 does not exist. Dropping to shell! usbcore: registered new interface driver usbhid usbhid: USB HID core driver - cat /proc/cmdline shows mac address that of usb-c network adapter. - cat /proc/modules includes “usbnet 45056 cdc_ether, Live 0xc009c000” - cat /proc/modules | grep usb … includes “ usbnet 45056 and usbhid 49152” I've tried enlisting with older boot image and different kernel versions (14.04 and 16.04 with ga-16.04, hwe-16.04 set) but get the same problem. It seems like the usb-c network adapter isn't loading properly or maybe just not quickly enough? Please let me know if you require any more info. I can provide info from /var/log/maas/* and dpkg -l '*maas*'|cat if need be. To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1639202/+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 1338706] Re: Samsung SSD 840 failed to get NCQ Send/Recv Log Emask 0x1 failed to set xfermode (err_mask=0x40) on upstream kernels >= 3.12
@evan
No, you are seeing a different or new bug.
--
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/1338706
Title:
Samsung SSD 840 failed to get NCQ Send/Recv Log Emask 0x1 failed to
set xfermode (err_mask=0x40) on upstream kernels >= 3.12
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Trusty:
Fix Released
Status in linux source package in Utopic:
Fix Released
Status in linux source package in Vivid:
Fix Released
Status in linux source package in Wily:
Fix Released
Bug description:
[Impact]
* Users with Samsung 8** SSD drives see miscellaneous errors and
warning messages in the logs depending on the firmware level of the
drive while booting or after running trim.
[Test Case]
* Run this script, and then check logs for errors.
#!/bin/bash
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
for i in {0..10} ; do
cp -r linux linux$i
done
rm -rf linux*
echo "sudo fstrim requires your password"
sudo fstrim ./
[Regression Potential]
* There is very little regression potential as this change simply
prevents NCQ trim from being used on Samsung 8** drives.
[Other Info]
* Commit is upstream.
* Greatly increasing the timeout for the drives seems to relieve the timeout
errors. This may be due to trimming large numbers of sectors with single
commands. It may be prudent for future upstream to break up large trims into
multiple requests on smaller regions.
===Original Bug description ==
Samsung SSD 840 Series failed to get NCQ Send/Recv Log Emask 0x1.
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: linux-image-3.13.0-30-generic 3.13.0-30.55
ProcVersionSignature: Ubuntu 3.13.0-30.55-generic 3.13.11.2
Uname: Linux 3.13.0-30-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/controlC0: user 2131 F pulseaudio
CurrentDesktop: Unity
Date: Mon Jul 7 20:01:28 2014
HibernationDevice: RESUME=UUID=685afcb7-7aa6-4048-af15-091d3bcd3b35
InstallationDate: Installed on 2014-06-22 (14 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
IwConfig:
eth0 no wireless extensions.
lono wireless extensions.
MachineType: System manufacturer System Product Name
ProcFB: 0 nouveaufb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.13.0-30-generic
root=UUID=d7c2e1cb-d046-460c-83b8-0cfbb330d095 ro quiet splash vt.handoff=7
RelatedPackageVersions:
linux-restricted-modules-3.13.0-30-generic N/A
linux-backports-modules-3.13.0-30-generic N/A
linux-firmware 1.127.4
RfKill:
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 09/10/2010
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 0901
dmi.board.asset.tag: To Be Filled By O.E.M.
dmi.board.name: M3N78-EM
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: Rev X.0x
dmi.chassis.asset.tag: Asset-1234567890
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.version: Chassis Version
dmi.modalias:
dmi:bvnAmericanMegatrendsInc.:bvr0901:bd09/10/2010:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKComputerINC.:rnM3N78-EM:rvrRevX.0x:cvnChassisManufacture:ct3:cvrChassisVersion:
dmi.product.name: System Product Name
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1338706/+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 1628363] Re: VIA VL812 hub stops working with 4.4.0-40.60
** Changed in: linux (Ubuntu) Status: Confirmed => Invalid ** Changed in: linux (Ubuntu Xenial) Status: In Progress => Invalid -- 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/1628363 Title: VIA VL812 hub stops working with 4.4.0-40.60 Status in linux package in Ubuntu: Invalid Status in linux source package in Xenial: Invalid Bug description: VIA VL812 hub stops working with 4.4.0-40.60. Works fine with 4.4.0-39.59. Logs include both boot with 4.4.0-39 *(most recent) and 4.4.0-40 (previous boot). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-generic 4.4.0.40.42 ProcVersionSignature: Ubuntu 4.4.0-39.59-generic 4.4.21 Uname: Linux 4.4.0-39-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 CurrentDesktop: Unity Date: Tue Sep 27 22:48:35 2016 HibernationDevice: RESUME=UUID=1cb62c08-3564-4d8a-846c-6963690d InstallationDate: Installed on 2016-01-15 (256 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160115) ProcFB: ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-39-generic root=UUID=029afe58-00c3-4872-9556-b3fd990c5cf1 ro quiet splash crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M scsi_mod.use_blk_mq=y dm_mod.use_blk_mq=y crashkernel=384M-:128M RelatedPackageVersions: linux-restricted-modules-4.4.0-39-generic N/A linux-backports-modules-4.4.0-39-generic N/A linux-firmware1.157.4 RfKill: SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/06/2013 dmi.bios.vendor: Intel Corp. dmi.bios.version: SIX7910J.86A.0594.2013.0806.2241 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: DX79SI dmi.board.vendor: Intel Corporation dmi.board.version: AAG28808-500 dmi.chassis.type: 3 dmi.modalias: dmi:bvnIntelCorp.:bvrSIX7910J.86A.0594.2013.0806.2241:bd08/06/2013:svn:pn:pvr:rvnIntelCorporation:rnDX79SI:rvrAAG28808-500:cvn:ct3:cvr: klp-taint: 12289 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1628363/+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 1628363] Re: VIA VL812 hub stops working with 4.4.0-40.60
So I just rebooted 4 times with the -40 kernel, and everything seems to be going well. I'm going to chalk this one up to hardware misbehaving. At least until someone else hits this as well. Keep in mind the hub, does not work in usb 3.0 mode. That is not what this bug is about. -- 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/1628363 Title: VIA VL812 hub stops working with 4.4.0-40.60 Status in linux package in Ubuntu: Invalid Status in linux source package in Xenial: Invalid Bug description: VIA VL812 hub stops working with 4.4.0-40.60. Works fine with 4.4.0-39.59. Logs include both boot with 4.4.0-39 *(most recent) and 4.4.0-40 (previous boot). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-generic 4.4.0.40.42 ProcVersionSignature: Ubuntu 4.4.0-39.59-generic 4.4.21 Uname: Linux 4.4.0-39-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 CurrentDesktop: Unity Date: Tue Sep 27 22:48:35 2016 HibernationDevice: RESUME=UUID=1cb62c08-3564-4d8a-846c-6963690d InstallationDate: Installed on 2016-01-15 (256 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160115) ProcFB: ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-39-generic root=UUID=029afe58-00c3-4872-9556-b3fd990c5cf1 ro quiet splash crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M scsi_mod.use_blk_mq=y dm_mod.use_blk_mq=y crashkernel=384M-:128M RelatedPackageVersions: linux-restricted-modules-4.4.0-39-generic N/A linux-backports-modules-4.4.0-39-generic N/A linux-firmware1.157.4 RfKill: SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/06/2013 dmi.bios.vendor: Intel Corp. dmi.bios.version: SIX7910J.86A.0594.2013.0806.2241 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: DX79SI dmi.board.vendor: Intel Corporation dmi.board.version: AAG28808-500 dmi.chassis.type: 3 dmi.modalias: dmi:bvnIntelCorp.:bvrSIX7910J.86A.0594.2013.0806.2241:bd08/06/2013:svn:pn:pvr:rvnIntelCorporation:rnDX79SI:rvrAAG28808-500:cvn:ct3:cvr: klp-taint: 12289 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1628363/+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 1628363] [NEW] VIA VL812 hub stops working with 4.4.0-40.60
Public bug reported: VIA VL812 hub stops working with 4.4.0-40.60. Works fine with 4.4.0-39.59. Logs include both boot with 4.4.0-39 *(most recent) and 4.4.0-40 (previous boot). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-generic 4.4.0.40.42 ProcVersionSignature: Ubuntu 4.4.0-39.59-generic 4.4.21 Uname: Linux 4.4.0-39-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 CurrentDesktop: Unity Date: Tue Sep 27 22:48:35 2016 HibernationDevice: RESUME=UUID=1cb62c08-3564-4d8a-846c-6963690d InstallationDate: Installed on 2016-01-15 (256 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160115) ProcFB: ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-39-generic root=UUID=029afe58-00c3-4872-9556-b3fd990c5cf1 ro quiet splash crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M scsi_mod.use_blk_mq=y dm_mod.use_blk_mq=y crashkernel=384M-:128M RelatedPackageVersions: linux-restricted-modules-4.4.0-39-generic N/A linux-backports-modules-4.4.0-39-generic N/A linux-firmware1.157.4 RfKill: SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/06/2013 dmi.bios.vendor: Intel Corp. dmi.bios.version: SIX7910J.86A.0594.2013.0806.2241 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: DX79SI dmi.board.vendor: Intel Corporation dmi.board.version: AAG28808-500 dmi.chassis.type: 3 dmi.modalias: dmi:bvnIntelCorp.:bvrSIX7910J.86A.0594.2013.0806.2241:bd08/06/2013:svn:pn:pvr:rvnIntelCorporation:rnDX79SI:rvrAAG28808-500:cvn:ct3:cvr: klp-taint: 12289 ** Affects: linux (Ubuntu) Importance: Undecided Status: Confirmed ** Tags: amd64 apport-bug package-from-proposed third-party-packages 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/1628363 Title: VIA VL812 hub stops working with 4.4.0-40.60 Status in linux package in Ubuntu: Confirmed Bug description: VIA VL812 hub stops working with 4.4.0-40.60. Works fine with 4.4.0-39.59. Logs include both boot with 4.4.0-39 *(most recent) and 4.4.0-40 (previous boot). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-generic 4.4.0.40.42 ProcVersionSignature: Ubuntu 4.4.0-39.59-generic 4.4.21 Uname: Linux 4.4.0-39-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 CurrentDesktop: Unity Date: Tue Sep 27 22:48:35 2016 HibernationDevice: RESUME=UUID=1cb62c08-3564-4d8a-846c-6963690d InstallationDate: Installed on 2016-01-15 (256 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160115) ProcFB: ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-39-generic root=UUID=029afe58-00c3-4872-9556-b3fd990c5cf1 ro quiet splash crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M scsi_mod.use_blk_mq=y dm_mod.use_blk_mq=y crashkernel=384M-:128M RelatedPackageVersions: linux-restricted-modules-4.4.0-39-generic N/A linux-backports-modules-4.4.0-39-generic N/A linux-firmware1.157.4 RfKill: SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/06/2013 dmi.bios.vendor: Intel Corp. dmi.bios.version: SIX7910J.86A.0594.2013.0806.2241 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: DX79SI dmi.board.vendor: Intel Corporation dmi.board.version: AAG28808-500 dmi.chassis.type: 3 dmi.modalias: dmi:bvnIntelCorp.:bvrSIX7910J.86A.0594.2013.0806.2241:bd08/06/2013:svn:pn:pvr:rvnIntelCorporation:rnDX79SI:rvrAAG28808-500:cvn:ct3:cvr: klp-taint: 12289 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1628363/+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 1616193] Re: 3.13: libvirtd: page allocation failure: order:4, mode:0x1040d0
Marking verification-done-trusty, as the user has not replied back to me one way or the other so I'll assume their kernel is no longer getting allocation errors. I definitely don't want this pulled from the sources prematurely. ** Tags removed: verification-needed-trusty ** Tags added: verification-done-trusty -- 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/1616193 Title: 3.13: libvirtd: page allocation failure: order:4, mode:0x1040d0 Status in linux package in Ubuntu: Confirmed Status in linux source package in Trusty: Fix Committed Bug description: [Impact] * libvirtd is no longer able to open the vhost_net device. This causes the guest VM to hang. This happens if memory becomes fragmented to the point where vhost_net_open is not able to successfully kmalloc. * Gratuitous stack trace. libvirtd: page allocation failure: order:4, mode:0x1040d0 CPU: 14 PID: 82768 Comm: libvirtd Not tainted 3.13.0-85-generic #129-Ubuntu Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.5.4 10/002/2015 88003b419990 8172b6a7 001040d0 88003b419a18 811580eb 88187fffce48 88003b4199b8 8115abd6 88003b4199e8 0286 Call Trace: [] dump_stack+0x64/0x82 [] warn_alloc_failed+0xeb/0x140 [] ? drain_local_pages+0x16/0x20 [] __alloc_pages_nodemask+0x980/0xb90 [] alloc_pages_current+0xa3/0x160 [] __get_free_pages+0xe/0x50 [] kmalloc_order_trace+0x2e/0xc0 [] vhost_net_open+0x29/0x1b0 [vhost_net] [] misc_open+0xb3/0x170 [] chrdev_open+0x9f/0x1d0 [] do_dentry_open+0x233/0x2e0 [] ? cdev_put+0x30/0x30 [] vfs_open+0x49/0x50 [] do_last+0x562/0x1370 [] path_openat+0xbb/0x670 [] do_filp_open+0x3a/0x90 [] ? __alloc_fd+0xa7/0x130 [] do_sys_open+0x129/0x2a0 [] SyS_open+0x1e/0x20 [] system_call_fastpath+0x1a/0x1f * justification: because cloud. * The patches fix this issue by allowing vhost_net_open to use vmalloc when kmalloc fails to find a sufficient page size. [Test Case] * Fragment Kernel memory. Write to Nic from within a kvm guest that uses a virtio nic. [Regression Potential] * Fix was implemented upstream in 3.15, and still exists. * The fix is fairly straightfoward given the stack trace and the upstream fix. * The fix is hard to verify, as it requires significant memory fragmentation, and an over-active guest. The users machine that was experiencing this has worked around this by removing VM's from the compute host, and using vfs.cache.pressure=600. [Other Info] * https://lkml.org/lkml/2013/1/23/492 * http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=23cc5a991c7a9fb7e6d6550e65cee4f4173111c5 * http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d04257b07f2362d4eb550952d5bf5f4241a8046d * I'm going on vacation, and Eric Desrochers will be following up on this in my absence. This is also the reason for submitting before receiving verification. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1616193/+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 1579917] Re: Skylake processor never reaches low power states on X1 Carbon gen 4 with NVMe drive
Closing as invalid, as the root cause was clearly the IMEI firmware in my case, and has since been verified. ** Changed in: linux (Ubuntu) Status: Triaged => Invalid -- 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/1579917 Title: Skylake processor never reaches low power states on X1 Carbon gen 4 with NVMe drive Status in linux package in Ubuntu: Invalid Bug description: Reproducer 1. Find a skylake machine. - in my case Lenovo x1 carbon gen 4. In my case with an NVME drive. 2. run powertop, and switch to idle stats tab 3. do nothing. *(as in let the machine idle till the cores regularly reach low power states. 4. Watch the watts fly. On my machine the package never gets into any power state other than PC2. Expected results: PC3-PC10 power states should all show some usage. I also tried the mainline build of 4.6-rc7 with no benefits. Public conversations about the issue https://mjg59.dreamwidth.org/42156.html https://mjg59.dreamwidth.org/41713.html As far as I can tell having the nvme drive is part of the overall problem here. Please keep this case to skylake + nvme. Skylake + sata appears to have a number of fixes in the 4.6 and newer kernels that enable some of the higher sleep states, but I have not tested with a sata drive. Those fixes as of testing 4.6-rc7 do not resolve this issue with users who have nvme drives. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-22-generic 4.4.0-22.39 ProcVersionSignature: Ubuntu 4.4.0-22.39-generic 4.4.8 Uname: Linux 4.4.0-22-generic x86_64 ApportVersion: 2.20.1-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: chiluk 3139 F pulseaudio CurrentDesktop: Unity Date: Mon May 9 15:55:03 2016 HibernationDevice: RESUME=UUID=4f4ea88e-642e-4be5-bdf0-bbc7f47f5628 InstallationDate: Installed on 2016-04-25 (14 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 04f2:b531 Chicony Electronics Co., Ltd Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: LENOVO 20FBCTO1WW ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-22-generic.efi.signed root=UUID=249f91bb-7789-41cc-9cc0-8ba25d7f55bb ro quiet splash pcie_aspm=force vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-4.4.0-22-generic N/A linux-backports-modules-4.4.0-22-generic N/A linux-firmware1.157 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/15/2016 dmi.bios.vendor: LENOVO dmi.bios.version: N1FET37W (1.11 ) dmi.board.asset.tag: Not Available dmi.board.name: 20FBCTO1WW dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN1FET37W(1.11):bd03/15/2016:svnLENOVO:pn20FBCTO1WW:pvrThinkPadX1Carbon4th:rvnLENOVO:rn20FBCTO1WW:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrNone: dmi.product.name: 20FBCTO1WW dmi.product.version: ThinkPad X1 Carbon 4th dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1579917/+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 1579917] Re: Skylake processor never reaches low power states on X1 Carbon gen 4 with NVMe drive
IMEI firmware update definitely appears to be the fix as it is now verified independently. https://bugzilla.kernel.org/show_bug.cgi?id=116591 ** Bug watch added: Linux Kernel Bug Tracker #116591 http://bugzilla.kernel.org/show_bug.cgi?id=116591 -- 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/1579917 Title: Skylake processor never reaches low power states on X1 Carbon gen 4 with NVMe drive Status in linux package in Ubuntu: Triaged Bug description: Reproducer 1. Find a skylake machine. - in my case Lenovo x1 carbon gen 4. In my case with an NVME drive. 2. run powertop, and switch to idle stats tab 3. do nothing. *(as in let the machine idle till the cores regularly reach low power states. 4. Watch the watts fly. On my machine the package never gets into any power state other than PC2. Expected results: PC3-PC10 power states should all show some usage. I also tried the mainline build of 4.6-rc7 with no benefits. Public conversations about the issue https://mjg59.dreamwidth.org/42156.html https://mjg59.dreamwidth.org/41713.html As far as I can tell having the nvme drive is part of the overall problem here. Please keep this case to skylake + nvme. Skylake + sata appears to have a number of fixes in the 4.6 and newer kernels that enable some of the higher sleep states, but I have not tested with a sata drive. Those fixes as of testing 4.6-rc7 do not resolve this issue with users who have nvme drives. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-22-generic 4.4.0-22.39 ProcVersionSignature: Ubuntu 4.4.0-22.39-generic 4.4.8 Uname: Linux 4.4.0-22-generic x86_64 ApportVersion: 2.20.1-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: chiluk 3139 F pulseaudio CurrentDesktop: Unity Date: Mon May 9 15:55:03 2016 HibernationDevice: RESUME=UUID=4f4ea88e-642e-4be5-bdf0-bbc7f47f5628 InstallationDate: Installed on 2016-04-25 (14 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 04f2:b531 Chicony Electronics Co., Ltd Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: LENOVO 20FBCTO1WW ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-22-generic.efi.signed root=UUID=249f91bb-7789-41cc-9cc0-8ba25d7f55bb ro quiet splash pcie_aspm=force vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-4.4.0-22-generic N/A linux-backports-modules-4.4.0-22-generic N/A linux-firmware1.157 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/15/2016 dmi.bios.vendor: LENOVO dmi.bios.version: N1FET37W (1.11 ) dmi.board.asset.tag: Not Available dmi.board.name: 20FBCTO1WW dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN1FET37W(1.11):bd03/15/2016:svnLENOVO:pn20FBCTO1WW:pvrThinkPadX1Carbon4th:rvnLENOVO:rn20FBCTO1WW:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrNone: dmi.product.name: 20FBCTO1WW dmi.product.version: ThinkPad X1 Carbon 4th dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1579917/+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 1616193] Re: 3.13: libvirtd: page allocation failure: order:4, mode:0x1040d0
Fix submitted to kernel-t...@lists.ubuntu.com. ** Description changed: - [Impact] - * libvirtd is no longer able to open the vhost_net device. This causes the guest VM to hang. This happens if memory becomes fragmented to the point where vhost_net_open is not able to successfully kmalloc. + [Impact] + * libvirtd is no longer able to open the vhost_net device. This causes the guest VM to hang. This happens if memory becomes fragmented to the point where vhost_net_open is not able to successfully kmalloc. - * Gratuitous stack trace. + * Gratuitous stack trace. libvirtd: page allocation failure: order:4, mode:0x1040d0 CPU: 14 PID: 82768 Comm: libvirtd Not tainted 3.13.0-85-generic #129-Ubuntu Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.5.4 10/002/2015 - 88003b419990 8172b6a7 001040d0 - 88003b419a18 811580eb 88187fffce48 - 88003b4199b8 8115abd6 88003b4199e8 0286 + 88003b419990 8172b6a7 001040d0 + 88003b419a18 811580eb 88187fffce48 + 88003b4199b8 8115abd6 88003b4199e8 0286 Call Trace: - [] dump_stack+0x64/0x82 - [] warn_alloc_failed+0xeb/0x140 - [] ? drain_local_pages+0x16/0x20 - [] __alloc_pages_nodemask+0x980/0xb90 - [] alloc_pages_current+0xa3/0x160 - [] __get_free_pages+0xe/0x50 - [] kmalloc_order_trace+0x2e/0xc0 - [] vhost_net_open+0x29/0x1b0 [vhost_net] - [] misc_open+0xb3/0x170 - [] chrdev_open+0x9f/0x1d0 - [] do_dentry_open+0x233/0x2e0 - [] ? cdev_put+0x30/0x30 - [] vfs_open+0x49/0x50 - [] do_last+0x562/0x1370 - [] path_openat+0xbb/0x670 - [] do_filp_open+0x3a/0x90 - [] ? __alloc_fd+0xa7/0x130 - [] do_sys_open+0x129/0x2a0 - [] SyS_open+0x1e/0x20 - [] system_call_fastpath+0x1a/0x1f + [] dump_stack+0x64/0x82 + [] warn_alloc_failed+0xeb/0x140 + [] ? drain_local_pages+0x16/0x20 + [] __alloc_pages_nodemask+0x980/0xb90 + [] alloc_pages_current+0xa3/0x160 + [] __get_free_pages+0xe/0x50 + [] kmalloc_order_trace+0x2e/0xc0 + [] vhost_net_open+0x29/0x1b0 [vhost_net] + [] misc_open+0xb3/0x170 + [] chrdev_open+0x9f/0x1d0 + [] do_dentry_open+0x233/0x2e0 + [] ? cdev_put+0x30/0x30 + [] vfs_open+0x49/0x50 + [] do_last+0x562/0x1370 + [] path_openat+0xbb/0x670 + [] do_filp_open+0x3a/0x90 + [] ? __alloc_fd+0xa7/0x130 + [] do_sys_open+0x129/0x2a0 + [] SyS_open+0x1e/0x20 + [] system_call_fastpath+0x1a/0x1f - * justification: cloud. + * justification: because cloud. - * The patches fix this issue by allowing vhost_net_open to use vmalloc - when kmalloc fails to find a sufficient page. + * The patches fix this issue by allowing vhost_net_open to use vmalloc + when kmalloc fails to find a sufficient page size. [Test Case] - * Fragment Kernel memory. Write to Nic from within a kvm guest that + * Fragment Kernel memory. Write to Nic from within a kvm guest that uses a virtio nic. [Regression Potential] - * Fix was implemented upstream in 3.15, and still exists. + * Fix was implemented upstream in 3.15, and still exists. - * Testing TBD + * The fix is fairly straightfoward given the stack trace and the + upstream fix. + + * The fix is hard to verify, as it requires significant memory + fragmentation, and an over-active guest. The users machine that was + experiencing this has worked around this by removing VM's from the + compute host, and using vfs.cache.pressure=600. [Other Info] - - * https://lkml.org/lkml/2013/1/23/492 - * http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=23cc5a991c7a9fb7e6d6550e65cee4f4173111c5 - * http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d04257b07f2362d4eb550952d5bf5f4241a8046d + + * https://lkml.org/lkml/2013/1/23/492 + * http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=23cc5a991c7a9fb7e6d6550e65cee4f4173111c5 + * http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d04257b07f2362d4eb550952d5bf5f4241a8046d + * I'm going on vacation, and Eric Desrochers will be following up on this in my absence. This is also the reason for submitting before receiving verification. -- 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/1616193 Title: 3.13: libvirtd: page allocation failure: order:4, mode:0x1040d0 Status in linux package in Ubuntu: Confirmed Bug description: [Impact] * libvirtd is no longer able to open the vhost_net device. This causes the guest VM to hang. This happens if memory becomes fragmented to the point where vhost_net_open is not able to successfully kmalloc. * Gratuitous stack trace. libvirtd: page allocation failure: order:4, mode:0x1040d0 CPU: 14 PID: 82768 Comm: libvirtd Not tainted 3.13.0-85-generic #129-Ubuntu Hardware name: Dell
[Kernel-packages] [Bug 1616193] Re: 3.13: libvirtd: page allocation failure: order:4, mode:0x1040d0
Shut the front door bug-bot.
** 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/1616193
Title:
3.13: libvirtd: page allocation failure: order:4, mode:0x1040d0
Status in linux package in Ubuntu:
Confirmed
Bug description:
[Impact]
* libvirtd is no longer able to open the vhost_net device. This causes the
guest VM to hang. This happens if memory becomes fragmented to the point where
vhost_net_open is not able to successfully kmalloc.
* Gratuitous stack trace.
libvirtd: page allocation failure: order:4, mode:0x1040d0
CPU: 14 PID: 82768 Comm: libvirtd Not tainted 3.13.0-85-generic #129-Ubuntu
Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.5.4 10/002/2015
88003b419990 8172b6a7 001040d0
88003b419a18 811580eb 88187fffce48
88003b4199b8 8115abd6 88003b4199e8 0286
Call Trace:
[] dump_stack+0x64/0x82
[] warn_alloc_failed+0xeb/0x140
[] ? drain_local_pages+0x16/0x20
[] __alloc_pages_nodemask+0x980/0xb90
[] alloc_pages_current+0xa3/0x160
[] __get_free_pages+0xe/0x50
[] kmalloc_order_trace+0x2e/0xc0
[] vhost_net_open+0x29/0x1b0 [vhost_net]
[] misc_open+0xb3/0x170
[] chrdev_open+0x9f/0x1d0
[] do_dentry_open+0x233/0x2e0
[] ? cdev_put+0x30/0x30
[] vfs_open+0x49/0x50
[] do_last+0x562/0x1370
[] path_openat+0xbb/0x670
[] do_filp_open+0x3a/0x90
[] ? __alloc_fd+0xa7/0x130
[] do_sys_open+0x129/0x2a0
[] SyS_open+0x1e/0x20
[] system_call_fastpath+0x1a/0x1f
* justification: cloud.
* The patches fix this issue by allowing vhost_net_open to use
vmalloc when kmalloc fails to find a sufficient page.
[Test Case]
* Fragment Kernel memory. Write to Nic from within a kvm guest that
uses a virtio nic.
[Regression Potential]
* Fix was implemented upstream in 3.15, and still exists.
* Testing TBD
[Other Info]
* https://lkml.org/lkml/2013/1/23/492
*
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=23cc5a991c7a9fb7e6d6550e65cee4f4173111c5
*
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d04257b07f2362d4eb550952d5bf5f4241a8046d
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1616193/+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 1616193] [NEW] 3.13: libvirtd: page allocation failure: order:4, mode:0x1040d0
Public bug reported:
[Impact]
* libvirtd is no longer able to open the vhost_net device. This causes the
guest VM to hang. This happens if memory becomes fragmented to the point where
vhost_net_open is not able to successfully kmalloc.
* Gratuitous stack trace.
libvirtd: page allocation failure: order:4, mode:0x1040d0
CPU: 14 PID: 82768 Comm: libvirtd Not tainted 3.13.0-85-generic #129-Ubuntu
Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.5.4 10/002/2015
88003b419990 8172b6a7 001040d0
88003b419a18 811580eb 88187fffce48
88003b4199b8 8115abd6 88003b4199e8 0286
Call Trace:
[] dump_stack+0x64/0x82
[] warn_alloc_failed+0xeb/0x140
[] ? drain_local_pages+0x16/0x20
[] __alloc_pages_nodemask+0x980/0xb90
[] alloc_pages_current+0xa3/0x160
[] __get_free_pages+0xe/0x50
[] kmalloc_order_trace+0x2e/0xc0
[] vhost_net_open+0x29/0x1b0 [vhost_net]
[] misc_open+0xb3/0x170
[] chrdev_open+0x9f/0x1d0
[] do_dentry_open+0x233/0x2e0
[] ? cdev_put+0x30/0x30
[] vfs_open+0x49/0x50
[] do_last+0x562/0x1370
[] path_openat+0xbb/0x670
[] do_filp_open+0x3a/0x90
[] ? __alloc_fd+0xa7/0x130
[] do_sys_open+0x129/0x2a0
[] SyS_open+0x1e/0x20
[] system_call_fastpath+0x1a/0x1f
* justification: cloud.
* The patches fix this issue by allowing vhost_net_open to use vmalloc
when kmalloc fails to find a sufficient page.
[Test Case]
* Fragment Kernel memory. Write to Nic from within a kvm guest that
uses a virtio nic.
[Regression Potential]
* Fix was implemented upstream in 3.15, and still exists.
* Testing TBD
[Other Info]
* https://lkml.org/lkml/2013/1/23/492
*
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=23cc5a991c7a9fb7e6d6550e65cee4f4173111c5
*
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d04257b07f2362d4eb550952d5bf5f4241a8046d
** Affects: linux (Ubuntu)
Importance: Undecided
Assignee: Dave Chiluk (chiluk)
Status: New
** Tags: sts
** Attachment added: "Additional var/log/kern.log output showing fragmentation"
https://bugs.launchpad.net/bugs/1616193/+attachment/4726550/+files/bug.txt
--
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/1616193
Title:
3.13: libvirtd: page allocation failure: order:4, mode:0x1040d0
Status in linux package in Ubuntu:
New
Bug description:
[Impact]
* libvirtd is no longer able to open the vhost_net device. This causes the
guest VM to hang. This happens if memory becomes fragmented to the point where
vhost_net_open is not able to successfully kmalloc.
* Gratuitous stack trace.
libvirtd: page allocation failure: order:4, mode:0x1040d0
CPU: 14 PID: 82768 Comm: libvirtd Not tainted 3.13.0-85-generic #129-Ubuntu
Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.5.4 10/002/2015
88003b419990 8172b6a7 001040d0
88003b419a18 811580eb 88187fffce48
88003b4199b8 8115abd6 88003b4199e8 0286
Call Trace:
[] dump_stack+0x64/0x82
[] warn_alloc_failed+0xeb/0x140
[] ? drain_local_pages+0x16/0x20
[] __alloc_pages_nodemask+0x980/0xb90
[] alloc_pages_current+0xa3/0x160
[] __get_free_pages+0xe/0x50
[] kmalloc_order_trace+0x2e/0xc0
[] vhost_net_open+0x29/0x1b0 [vhost_net]
[] misc_open+0xb3/0x170
[] chrdev_open+0x9f/0x1d0
[] do_dentry_open+0x233/0x2e0
[] ? cdev_put+0x30/0x30
[] vfs_open+0x49/0x50
[] do_last+0x562/0x1370
[] path_openat+0xbb/0x670
[] do_filp_open+0x3a/0x90
[] ? __alloc_fd+0xa7/0x130
[] do_sys_open+0x129/0x2a0
[] SyS_open+0x1e/0x20
[] system_call_fastpath+0x1a/0x1f
* justification: cloud.
* The patches fix this issue by allowing vhost_net_open to use
vmalloc when kmalloc fails to find a sufficient page.
[Test Case]
* Fragment Kernel memory. Write to Nic from within a kvm guest that
uses a virtio nic.
[Regression Potential]
* Fix was implemented upstream in 3.15, and still exists.
* Testing TBD
[Other Info]
* https://lkml.org/lkml/2013/1/23/492
*
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=23cc5a991c7a9fb7e6d6550e65cee4f4173111c5
*
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d04257b07f2362d4eb550952d5bf5f4241a8046d
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1616193/+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 1581236] Re: Power state does not drop lower than pc03 for package (Haswell i7-4500U)
I was able to remove the nvidia card from my desktop and check again. Removing the nvidia card and enabling the integrated graphics resulted in my machine reaching pc6. So I'll leave this as expired for the time being. -- 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/1581236 Title: Power state does not drop lower than pc03 for package (Haswell i7-4500U) Status in linux package in Ubuntu: Expired Bug description: So similarly to bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1579917, I am also not able to get into pc10, as described there. I am using a sata drive, and after setting min_power to /sys/class/scsi_host/*/link_power_management_policy still does not get me into any states lower than pc03. Following these links -- without testing the patched kernel (Setting min_power gets me to pc03, but not any further) https://mjg59.dreamwidth.org/42156.html https://mjg59.dreamwidth.org/41713.html Attaching the powertop screencap: http://pastebin.ubuntu.com/16382692/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1581236/+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 1607920] Re: zfs services fail on firstboot if zfs-utils is integrated into the deployment image
Personally I think we should modify MNTTAB in zfs-linux to point to /proc/self/mounts. This may not be completely straightforward *(there are a number of places that point to /etc/mnttab directly, or have logic around it and /proc/mounts), but it should be doable. I like this solution most because it doesn't require us to increase the number of dependencies in the zfs systemd scripts. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to zfs-linux in Ubuntu. https://bugs.launchpad.net/bugs/1607920 Title: zfs services fail on firstboot if zfs-utils is integrated into the deployment image Status in sysvinit package in Ubuntu: New Status in zfs-linux package in Ubuntu: New Bug description: [Impact] * zfs services fail on firstboot if zfs-utils is integrated into the deployment image. * Output from systemd - sudo systemctl --failed UNIT LOAD ACTIVE SUB DESCRIPTION ● zfs-import-scan.service loaded failed failed Import ZFS pools by device scanning ● zfs-mount.service loaded failed failed Mount ZFS filesystems * This is particularly frustrating for users who use automated monitoring as it means virtual machines must always be restarted before showing as clean. * This failure is due to zfs services starting up before /etc/mtab has a chance to be symlinked to /proc/mounts. [Test Case] 1. Grab a stock xenial image, and unpack it and add zfs-utils to it. Repack it. 2. Boot machine 3. Check systemctl --failed. [Regression Potential] * [Other Info] * This can likely be resolved in the systemd init scripts, by modifying zfs-linux to depend on /proc/mounts instead, or inclusion of /lib/init/mount-functions.sh in initscripts (sysvinit). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1607920/+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 1607920] [NEW] zfs services fail on firstboot if zfs-utils is integrated into the deployment image
Public bug reported: [Impact] * zfs services fail on firstboot if zfs-utils is integrated into the deployment image. * Output from systemd - sudo systemctl --failed UNIT LOAD ACTIVE SUB DESCRIPTION ● zfs-import-scan.service loaded failed failed Import ZFS pools by device scanning ● zfs-mount.service loaded failed failed Mount ZFS filesystems * This is particularly frustrating for users who use automated monitoring as it means virtual machines must always be restarted before showing as clean. * This failure is due to zfs services starting up before /etc/mtab has a chance to be symlinked to /proc/mounts. [Test Case] 1. Grab a stock xenial image, and unpack it and add zfs-utils to it. Repack it. 2. Boot machine 3. Check systemctl --failed. [Regression Potential] * [Other Info] * This can likely be resolved in the systemd init scripts, by modifying zfs-linux to depend on /proc/mounts instead, or inclusion of /lib/init/mount-functions.sh in initscripts (sysvinit). ** Affects: sysvinit (Ubuntu) Importance: Undecided Status: New ** Affects: zfs-linux (Ubuntu) Importance: Undecided Status: New ** Also affects: sysvinit (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to zfs-linux in Ubuntu. https://bugs.launchpad.net/bugs/1607920 Title: zfs services fail on firstboot if zfs-utils is integrated into the deployment image Status in sysvinit package in Ubuntu: New Status in zfs-linux package in Ubuntu: New Bug description: [Impact] * zfs services fail on firstboot if zfs-utils is integrated into the deployment image. * Output from systemd - sudo systemctl --failed UNIT LOAD ACTIVE SUB DESCRIPTION ● zfs-import-scan.service loaded failed failed Import ZFS pools by device scanning ● zfs-mount.service loaded failed failed Mount ZFS filesystems * This is particularly frustrating for users who use automated monitoring as it means virtual machines must always be restarted before showing as clean. * This failure is due to zfs services starting up before /etc/mtab has a chance to be symlinked to /proc/mounts. [Test Case] 1. Grab a stock xenial image, and unpack it and add zfs-utils to it. Repack it. 2. Boot machine 3. Check systemctl --failed. [Regression Potential] * [Other Info] * This can likely be resolved in the systemd init scripts, by modifying zfs-linux to depend on /proc/mounts instead, or inclusion of /lib/init/mount-functions.sh in initscripts (sysvinit). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1607920/+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 1378123] Re: unix_socket_abstract.sh triggers an AppArmor WARN
** Changed in: linux (Ubuntu Wily) Status: Confirmed => Won't Fix ** Changed in: linux (Ubuntu Vivid) Status: Confirmed => Won't Fix -- 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/1378123 Title: unix_socket_abstract.sh triggers an AppArmor WARN Status in linux package in Ubuntu: Fix Released Status in linux source package in Vivid: Won't Fix Status in linux source package in Wily: Won't Fix Status in linux source package in Xenial: Fix Released Bug description: Running the unix_socket_abstract.sh regression test script in a loop results in an AppArmor WARN message in the logs. On my test system, it typically takes between 1 and 3 runs of unix_socket_abstract.sh before the WARN is hit. It does not seem to occur with the unix_socket_pathname.sh or unix_socket_unnamed.sh tests. Here's the script I used: --- #!/bin/sh dmesg -C while ! dmesg -c | grep "AppArmor WARN"; do bash unix_socket_abstract.sh done --- The following back trace is emitted in the logs: [ 1365.017477] [ cut here ] [ 1365.017486] WARNING: CPU: 0 PID: 26026 at /build/buildd/linux-3.16.0/security/apparmor/label.c:1767 __aa_labelset_update_all+0x6f5/0x7f0() [ 1365.017487] AppArmor WARN __label_update: ((__aa_label_remove_and_insert((&(((label)->ent[(label)->size - 1])->ns)->labels), label, l) != l)): [ 1365.017489] Modules linked in: bnep rfcomm bluetooth 6lowpan_iphc kvm_intel kvm vmwgfx ttm drm_kms_helper serio_raw drm i2c_piix4 pvpanic parport_pc ppdev mac_hid lp parport psmouse pata_acpi floppy [ 1365.017505] CPU: 0 PID: 26026 Comm: apparmor_parser Tainted: GW 3.16.0-20-generic #27-Ubuntu [ 1365.017507] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [ 1365.017509] 0009 88002dd23d88 8177f053 88002dd23dd0 [ 1365.017511] 88002dd23dc0 8106fcfd 880036602900 [ 1365.017513] 88003acaed00 0002 88003e02a0a0 88002dd23e20 [ 1365.017516] Call Trace: [ 1365.017522] [] dump_stack+0x45/0x56 [ 1365.017527] [] warn_slowpath_common+0x7d/0xa0 [ 1365.017530] [] warn_slowpath_fmt+0x4c/0x50 [ 1365.017533] [] ? __aa_label_remove_and_insert+0x7e/0x1a0 [ 1365.017536] [] __aa_labelset_update_all+0x6f5/0x7f0 [ 1365.017539] [] ? securityfs_remove+0x9a/0xb0 [ 1365.017542] [] aa_remove_profiles+0x143/0x4f0 [ 1365.017545] [] profile_remove+0x3e/0x70 [ 1365.017550] [] vfs_write+0xb7/0x1f0 [ 1365.017552] [] ? do_sys_open+0x1b9/0x280 [ 1365.017555] [] SyS_write+0x46/0xb0 [ 1365.017558] [] system_call_fastpath+0x1a/0x1f [ 1365.017560] ---[ end trace 1e09e2c565d9ef95 ]--- This occurs in an amd64 utopic vm: $ uname -a Linux sec-utopic-amd64 3.16.0-20-generic #27-Ubuntu SMP Wed Oct 1 17:35:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1378123/+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 1378123] Re: unix_socket_abstract.sh triggers an AppArmor WARN
Thanks guys, I really think the solution here will be to move onto the lts-xenial kernel as all others lts- kernels will be end of life shortly. -- 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/1378123 Title: unix_socket_abstract.sh triggers an AppArmor WARN Status in linux package in Ubuntu: Fix Released Status in linux source package in Vivid: Confirmed Status in linux source package in Wily: Confirmed Status in linux source package in Xenial: Fix Released Bug description: Running the unix_socket_abstract.sh regression test script in a loop results in an AppArmor WARN message in the logs. On my test system, it typically takes between 1 and 3 runs of unix_socket_abstract.sh before the WARN is hit. It does not seem to occur with the unix_socket_pathname.sh or unix_socket_unnamed.sh tests. Here's the script I used: --- #!/bin/sh dmesg -C while ! dmesg -c | grep "AppArmor WARN"; do bash unix_socket_abstract.sh done --- The following back trace is emitted in the logs: [ 1365.017477] [ cut here ] [ 1365.017486] WARNING: CPU: 0 PID: 26026 at /build/buildd/linux-3.16.0/security/apparmor/label.c:1767 __aa_labelset_update_all+0x6f5/0x7f0() [ 1365.017487] AppArmor WARN __label_update: ((__aa_label_remove_and_insert((&(((label)->ent[(label)->size - 1])->ns)->labels), label, l) != l)): [ 1365.017489] Modules linked in: bnep rfcomm bluetooth 6lowpan_iphc kvm_intel kvm vmwgfx ttm drm_kms_helper serio_raw drm i2c_piix4 pvpanic parport_pc ppdev mac_hid lp parport psmouse pata_acpi floppy [ 1365.017505] CPU: 0 PID: 26026 Comm: apparmor_parser Tainted: GW 3.16.0-20-generic #27-Ubuntu [ 1365.017507] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [ 1365.017509] 0009 88002dd23d88 8177f053 88002dd23dd0 [ 1365.017511] 88002dd23dc0 8106fcfd 880036602900 [ 1365.017513] 88003acaed00 0002 88003e02a0a0 88002dd23e20 [ 1365.017516] Call Trace: [ 1365.017522] [] dump_stack+0x45/0x56 [ 1365.017527] [] warn_slowpath_common+0x7d/0xa0 [ 1365.017530] [] warn_slowpath_fmt+0x4c/0x50 [ 1365.017533] [] ? __aa_label_remove_and_insert+0x7e/0x1a0 [ 1365.017536] [] __aa_labelset_update_all+0x6f5/0x7f0 [ 1365.017539] [] ? securityfs_remove+0x9a/0xb0 [ 1365.017542] [] aa_remove_profiles+0x143/0x4f0 [ 1365.017545] [] profile_remove+0x3e/0x70 [ 1365.017550] [] vfs_write+0xb7/0x1f0 [ 1365.017552] [] ? do_sys_open+0x1b9/0x280 [ 1365.017555] [] SyS_write+0x46/0xb0 [ 1365.017558] [] system_call_fastpath+0x1a/0x1f [ 1365.017560] ---[ end trace 1e09e2c565d9ef95 ]--- This occurs in an amd64 utopic vm: $ uname -a Linux sec-utopic-amd64 3.16.0-20-generic #27-Ubuntu SMP Wed Oct 1 17:35:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1378123/+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 1425803] Re: Driver problem with USB chipset VIA VL812-B2
"VIA Labs, Inc. (one of the largest manufacturers of USB 3.0 hub chipsets on the market) does not make an update program for Apple Mac OS X or Linux/Unix. " Vote with your wallets people. -- 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/1425803 Title: Driver problem with USB chipset VIA VL812-B2 Status in linux package in Ubuntu: Triaged Bug description: Presuming the system info you need is in the automatically generated collection from ubuntu-bug. Ubuntu 14.10, fully updated. Kernel 3.16.0-31-generic. The problem described also exists in earlier kernels although I cannot say when it first appeared. I have a HooToo HT-UH005 4-Port USB 3.0 hub (VIA VL812-B2 chipset) . I'm using it with a HP Pavilion 17-e049wm laptop. This computer has two USB 3.0 ports. When the computer is quiescent the CPU consumed is normally 0% to 1%. That's the same whether there are USB 2.0 or 3.0 devices plugged into its onboard USB 3.0 ports, or not. As soon as I plug the HT-UH005 hub into one of those USB 3.0 ports, a system process khubd appears and it takes about 7% of CPU. Also, several "kworker" and "ksoftirqd" threads appear which between them consume another 18% of CPU, for a total of 25% CPU load. That's just because the HT-UH005 was plugged in. No peripherals attached to the HT-UH005. Stranger still, when I unplug the HT-UH005 the khubd, kworker, and ksoftirqd threads *continue* to consume 25% CPU. That's with the HT- UH005 disconnected after it was previously connected. This goes on indefinitely. The only way I can get things back to normal is to reboot or to manually stop and restart (unbind and then bind) the xhci_hcd driver that's servicing the internal hub that runs the computer's two USB 3.0 ports. The listing from dmesg shows no apparent problems when the HT-UH005 is connected or disconnected. Listing from lsusb shows the HT-UH005 successfully connected to a port on the internal USB 3.0 hub using driver xhci_hcd. This could be caused by some sort of incompatibility between the AMD internal hub and the VIA external hub. But, that the condition persists after the HT- UH005 is disconnected suggests it is almost surely a linux driver problem. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: linux-image-3.16.0-31-generic 3.16.0-31.41 ProcVersionSignature: Ubuntu 3.16.0-31.41-generic 3.16.7-ckt5 Uname: Linux 3.16.0-31-generic x86_64 NonfreeKernelModules: wl fglrx ApportVersion: 2.14.7-0ubuntu8.2 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: warren 5539 F pulseaudio /dev/snd/controlC0: warren 5539 F pulseaudio CurrentDesktop: Unity Date: Wed Feb 25 22:12:53 2015 HibernationDevice: RESUME=UUID=d6ce9a82-d272-4efa-bfe4-e13c883b2418 InstallationDate: Installed on 2012-05-23 (1008 days ago) InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120425) MachineType: Hewlett-Packard HP Pavilion 17 Notebook PC ProcFB: 0 EFI VGA ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.16.0-31-generic root=UUID=515bfe03-1a57-4762-9cc1-6896e081c4c5 ro quiet splash rootfstype=ext4 vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-3.16.0-31-generic N/A linux-backports-modules-3.16.0-31-generic N/A linux-firmware 1.138.1 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/04/2013 dmi.bios.vendor: Insyde dmi.bios.version: F.31 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: 1984 dmi.board.vendor: Hewlett-Packard dmi.board.version: 01.13 dmi.chassis.type: 10 dmi.chassis.vendor: Hewlett-Packard dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnInsyde:bvrF.31:bd12/04/2013:svnHewlett-Packard:pnHPPavilion17NotebookPC:pvr088013305B1620100:rvnHewlett-Packard:rn1984:rvr01.13:cvnHewlett-Packard:ct10:cvrChassisVersion: dmi.product.name: HP Pavilion 17 Notebook PC dmi.product.version: 088013305B1620100 dmi.sys.vendor: Hewlett-Packard To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1425803/+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 1425803] Re: Driver problem with USB chipset VIA VL812-B2
@Warren, Has this been resolved yet in upstream? *(I'm asking for selfish reasons as I almost just bought one of these). Also if this still exists on the GenesysLogic 3520 (maybe 3521) hub that would likely require a separate change and as such should be a separate bug. -- 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/1425803 Title: Driver problem with USB chipset VIA VL812-B2 Status in linux package in Ubuntu: Triaged Bug description: Presuming the system info you need is in the automatically generated collection from ubuntu-bug. Ubuntu 14.10, fully updated. Kernel 3.16.0-31-generic. The problem described also exists in earlier kernels although I cannot say when it first appeared. I have a HooToo HT-UH005 4-Port USB 3.0 hub (VIA VL812-B2 chipset) . I'm using it with a HP Pavilion 17-e049wm laptop. This computer has two USB 3.0 ports. When the computer is quiescent the CPU consumed is normally 0% to 1%. That's the same whether there are USB 2.0 or 3.0 devices plugged into its onboard USB 3.0 ports, or not. As soon as I plug the HT-UH005 hub into one of those USB 3.0 ports, a system process khubd appears and it takes about 7% of CPU. Also, several "kworker" and "ksoftirqd" threads appear which between them consume another 18% of CPU, for a total of 25% CPU load. That's just because the HT-UH005 was plugged in. No peripherals attached to the HT-UH005. Stranger still, when I unplug the HT-UH005 the khubd, kworker, and ksoftirqd threads *continue* to consume 25% CPU. That's with the HT- UH005 disconnected after it was previously connected. This goes on indefinitely. The only way I can get things back to normal is to reboot or to manually stop and restart (unbind and then bind) the xhci_hcd driver that's servicing the internal hub that runs the computer's two USB 3.0 ports. The listing from dmesg shows no apparent problems when the HT-UH005 is connected or disconnected. Listing from lsusb shows the HT-UH005 successfully connected to a port on the internal USB 3.0 hub using driver xhci_hcd. This could be caused by some sort of incompatibility between the AMD internal hub and the VIA external hub. But, that the condition persists after the HT- UH005 is disconnected suggests it is almost surely a linux driver problem. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: linux-image-3.16.0-31-generic 3.16.0-31.41 ProcVersionSignature: Ubuntu 3.16.0-31.41-generic 3.16.7-ckt5 Uname: Linux 3.16.0-31-generic x86_64 NonfreeKernelModules: wl fglrx ApportVersion: 2.14.7-0ubuntu8.2 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: warren 5539 F pulseaudio /dev/snd/controlC0: warren 5539 F pulseaudio CurrentDesktop: Unity Date: Wed Feb 25 22:12:53 2015 HibernationDevice: RESUME=UUID=d6ce9a82-d272-4efa-bfe4-e13c883b2418 InstallationDate: Installed on 2012-05-23 (1008 days ago) InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120425) MachineType: Hewlett-Packard HP Pavilion 17 Notebook PC ProcFB: 0 EFI VGA ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.16.0-31-generic root=UUID=515bfe03-1a57-4762-9cc1-6896e081c4c5 ro quiet splash rootfstype=ext4 vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-3.16.0-31-generic N/A linux-backports-modules-3.16.0-31-generic N/A linux-firmware 1.138.1 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/04/2013 dmi.bios.vendor: Insyde dmi.bios.version: F.31 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: 1984 dmi.board.vendor: Hewlett-Packard dmi.board.version: 01.13 dmi.chassis.type: 10 dmi.chassis.vendor: Hewlett-Packard dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnInsyde:bvrF.31:bd12/04/2013:svnHewlett-Packard:pnHPPavilion17NotebookPC:pvr088013305B1620100:rvnHewlett-Packard:rn1984:rvr01.13:cvnHewlett-Packard:ct10:cvrChassisVersion: dmi.product.name: HP Pavilion 17 Notebook PC dmi.product.version: 088013305B1620100 dmi.sys.vendor: Hewlett-Packard To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1425803/+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 1378123] Re: unix_socket_abstract.sh triggers an AppArmor WARN
** Tags added: sts -- 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/1378123 Title: unix_socket_abstract.sh triggers an AppArmor WARN Status in linux package in Ubuntu: Confirmed Bug description: Running the unix_socket_abstract.sh regression test script in a loop results in an AppArmor WARN message in the logs. On my test system, it typically takes between 1 and 3 runs of unix_socket_abstract.sh before the WARN is hit. It does not seem to occur with the unix_socket_pathname.sh or unix_socket_unnamed.sh tests. Here's the script I used: --- #!/bin/sh dmesg -C while ! dmesg -c | grep "AppArmor WARN"; do bash unix_socket_abstract.sh done --- The following back trace is emitted in the logs: [ 1365.017477] [ cut here ] [ 1365.017486] WARNING: CPU: 0 PID: 26026 at /build/buildd/linux-3.16.0/security/apparmor/label.c:1767 __aa_labelset_update_all+0x6f5/0x7f0() [ 1365.017487] AppArmor WARN __label_update: ((__aa_label_remove_and_insert((&(((label)->ent[(label)->size - 1])->ns)->labels), label, l) != l)): [ 1365.017489] Modules linked in: bnep rfcomm bluetooth 6lowpan_iphc kvm_intel kvm vmwgfx ttm drm_kms_helper serio_raw drm i2c_piix4 pvpanic parport_pc ppdev mac_hid lp parport psmouse pata_acpi floppy [ 1365.017505] CPU: 0 PID: 26026 Comm: apparmor_parser Tainted: GW 3.16.0-20-generic #27-Ubuntu [ 1365.017507] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [ 1365.017509] 0009 88002dd23d88 8177f053 88002dd23dd0 [ 1365.017511] 88002dd23dc0 8106fcfd 880036602900 [ 1365.017513] 88003acaed00 0002 88003e02a0a0 88002dd23e20 [ 1365.017516] Call Trace: [ 1365.017522] [] dump_stack+0x45/0x56 [ 1365.017527] [] warn_slowpath_common+0x7d/0xa0 [ 1365.017530] [] warn_slowpath_fmt+0x4c/0x50 [ 1365.017533] [] ? __aa_label_remove_and_insert+0x7e/0x1a0 [ 1365.017536] [] __aa_labelset_update_all+0x6f5/0x7f0 [ 1365.017539] [] ? securityfs_remove+0x9a/0xb0 [ 1365.017542] [] aa_remove_profiles+0x143/0x4f0 [ 1365.017545] [] profile_remove+0x3e/0x70 [ 1365.017550] [] vfs_write+0xb7/0x1f0 [ 1365.017552] [] ? do_sys_open+0x1b9/0x280 [ 1365.017555] [] SyS_write+0x46/0xb0 [ 1365.017558] [] system_call_fastpath+0x1a/0x1f [ 1365.017560] ---[ end trace 1e09e2c565d9ef95 ]--- This occurs in an amd64 utopic vm: $ uname -a Linux sec-utopic-amd64 3.16.0-20-generic #27-Ubuntu SMP Wed Oct 1 17:35:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1378123/+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 1588944] Re: Incorrect 0% remaining battery detected forcing suspend
In case anyone else hits this on their laptop and would like to disable the auto-suspend, I installed dconf-editor, and changed critical- battery-action to nothing. -- 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/1588944 Title: Incorrect 0% remaining battery detected forcing suspend Status in indicator-power package in Ubuntu: Invalid Status in linux package in Ubuntu: Invalid Status in upower package in Ubuntu: Invalid Bug description: Ubuntu is detecting that my battery has depleted to low or 0% which results in the OS forcing suspend. Normally this would be correct behavior, but in my case the battery has closer to 90% of remaining battery left. I have experienced this with 4.4.0-22 and 4.4.0-23, and am currently running 4.4.0-21 to see if it reproduces there as well. I do have -proposed enabled so it's a bit hard to determine if this is the kernel or something higher up the stack. This does seem to be mildly reproducible. 4.4.0-23 being the most problematic kernel so far. Of course this is a relatively new laptop so this could be a hardware issue as well. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-21-generic 4.4.0-21.37 ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6 Uname: Linux 4.4.0-21-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: chiluk 2462 F pulseaudio CurrentDesktop: Unity Date: Fri Jun 3 14:07:17 2016 HibernationDevice: RESUME=UUID=4f4ea88e-642e-4be5-bdf0-bbc7f47f5628 InstallationDate: Installed on 2016-04-25 (38 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 04f2:b531 Chicony Electronics Co., Ltd Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: LENOVO 20FBCTO1WW ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-21-generic root=UUID=249f91bb-7789-41cc-9cc0-8ba25d7f55bb ro quiet splash pcie_aspm=force vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-4.4.0-21-generic N/A linux-backports-modules-4.4.0-21-generic N/A linux-firmware1.157 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/18/2016 dmi.bios.vendor: LENOVO dmi.bios.version: N1FET40W (1.14 ) dmi.board.asset.tag: Not Available dmi.board.name: 20FBCTO1WW dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN1FET40W(1.14):bd04/18/2016:svnLENOVO:pn20FBCTO1WW:pvrThinkPadX1Carbon4th:rvnLENOVO:rn20FBCTO1WW:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrNone: dmi.product.name: 20FBCTO1WW dmi.product.version: ThinkPad X1 Carbon 4th dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/indicator-power/+bug/1588944/+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 1579917] Re: Skylake processor never reaches low power states on X1 Carbon gen 4 with NVMe drive
Sorry hit post too quickly. Anyhow, so it looks like upgrading the IMEI firmware now allows my amt/vpro capable laptop to reach low-power power pc-states. -- 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/1579917 Title: Skylake processor never reaches low power states on X1 Carbon gen 4 with NVMe drive Status in linux package in Ubuntu: Triaged Bug description: Reproducer 1. Find a skylake machine. - in my case Lenovo x1 carbon gen 4. In my case with an NVME drive. 2. run powertop, and switch to idle stats tab 3. do nothing. *(as in let the machine idle till the cores regularly reach low power states. 4. Watch the watts fly. On my machine the package never gets into any power state other than PC2. Expected results: PC3-PC10 power states should all show some usage. I also tried the mainline build of 4.6-rc7 with no benefits. Public conversations about the issue https://mjg59.dreamwidth.org/42156.html https://mjg59.dreamwidth.org/41713.html As far as I can tell having the nvme drive is part of the overall problem here. Please keep this case to skylake + nvme. Skylake + sata appears to have a number of fixes in the 4.6 and newer kernels that enable some of the higher sleep states, but I have not tested with a sata drive. Those fixes as of testing 4.6-rc7 do not resolve this issue with users who have nvme drives. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-22-generic 4.4.0-22.39 ProcVersionSignature: Ubuntu 4.4.0-22.39-generic 4.4.8 Uname: Linux 4.4.0-22-generic x86_64 ApportVersion: 2.20.1-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: chiluk 3139 F pulseaudio CurrentDesktop: Unity Date: Mon May 9 15:55:03 2016 HibernationDevice: RESUME=UUID=4f4ea88e-642e-4be5-bdf0-bbc7f47f5628 InstallationDate: Installed on 2016-04-25 (14 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 04f2:b531 Chicony Electronics Co., Ltd Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: LENOVO 20FBCTO1WW ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-22-generic.efi.signed root=UUID=249f91bb-7789-41cc-9cc0-8ba25d7f55bb ro quiet splash pcie_aspm=force vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-4.4.0-22-generic N/A linux-backports-modules-4.4.0-22-generic N/A linux-firmware1.157 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/15/2016 dmi.bios.vendor: LENOVO dmi.bios.version: N1FET37W (1.11 ) dmi.board.asset.tag: Not Available dmi.board.name: 20FBCTO1WW dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN1FET37W(1.11):bd03/15/2016:svnLENOVO:pn20FBCTO1WW:pvrThinkPadX1Carbon4th:rvnLENOVO:rn20FBCTO1WW:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrNone: dmi.product.name: 20FBCTO1WW dmi.product.version: ThinkPad X1 Carbon 4th dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1579917/+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 1579917] Re: Skylake processor never reaches low power states on X1 Carbon gen 4 with NVMe drive
So I recently had to run a certain Microsoft OS while debugging another issue. I ran a number updates during that session. The most important of which was an IMEI firmware update. I can't prove for certain that the IMEI firmware update resolved this issue, but it is the mostly likely considering every other update was unrelated to firmware bios or power. -- 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/1579917 Title: Skylake processor never reaches low power states on X1 Carbon gen 4 with NVMe drive Status in linux package in Ubuntu: Triaged Bug description: Reproducer 1. Find a skylake machine. - in my case Lenovo x1 carbon gen 4. In my case with an NVME drive. 2. run powertop, and switch to idle stats tab 3. do nothing. *(as in let the machine idle till the cores regularly reach low power states. 4. Watch the watts fly. On my machine the package never gets into any power state other than PC2. Expected results: PC3-PC10 power states should all show some usage. I also tried the mainline build of 4.6-rc7 with no benefits. Public conversations about the issue https://mjg59.dreamwidth.org/42156.html https://mjg59.dreamwidth.org/41713.html As far as I can tell having the nvme drive is part of the overall problem here. Please keep this case to skylake + nvme. Skylake + sata appears to have a number of fixes in the 4.6 and newer kernels that enable some of the higher sleep states, but I have not tested with a sata drive. Those fixes as of testing 4.6-rc7 do not resolve this issue with users who have nvme drives. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-22-generic 4.4.0-22.39 ProcVersionSignature: Ubuntu 4.4.0-22.39-generic 4.4.8 Uname: Linux 4.4.0-22-generic x86_64 ApportVersion: 2.20.1-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: chiluk 3139 F pulseaudio CurrentDesktop: Unity Date: Mon May 9 15:55:03 2016 HibernationDevice: RESUME=UUID=4f4ea88e-642e-4be5-bdf0-bbc7f47f5628 InstallationDate: Installed on 2016-04-25 (14 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 04f2:b531 Chicony Electronics Co., Ltd Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: LENOVO 20FBCTO1WW ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-22-generic.efi.signed root=UUID=249f91bb-7789-41cc-9cc0-8ba25d7f55bb ro quiet splash pcie_aspm=force vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-4.4.0-22-generic N/A linux-backports-modules-4.4.0-22-generic N/A linux-firmware1.157 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/15/2016 dmi.bios.vendor: LENOVO dmi.bios.version: N1FET37W (1.11 ) dmi.board.asset.tag: Not Available dmi.board.name: 20FBCTO1WW dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN1FET37W(1.11):bd03/15/2016:svnLENOVO:pn20FBCTO1WW:pvrThinkPadX1Carbon4th:rvnLENOVO:rn20FBCTO1WW:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrNone: dmi.product.name: 20FBCTO1WW dmi.product.version: ThinkPad X1 Carbon 4th dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1579917/+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 1581236] Re: Power state does not drop lower than pc03 for package (Haswell i7-4500U)
@Greg Our Haswell servers aren't seeing this, but one of my desktops is. By chance do you happen to have an nvidia card in that machine? I've been meaning to rip it out of my desktop and try again, but I haven't found the time. Also please run apport-collect and upload the logs to this case. Thank you, -- 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/1581236 Title: Power state does not drop lower than pc03 for package (Haswell i7-4500U) Status in linux package in Ubuntu: Incomplete Bug description: So similarly to bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1579917, I am also not able to get into pc10, as described there. I am using a sata drive, and after setting min_power to /sys/class/scsi_host/*/link_power_management_policy still does not get me into any states lower than pc03. Following these links -- without testing the patched kernel (Setting min_power gets me to pc03, but not any further) https://mjg59.dreamwidth.org/42156.html https://mjg59.dreamwidth.org/41713.html Attaching the powertop screencap: http://pastebin.ubuntu.com/16382692/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1581236/+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 1588944] Re: Incorrect 0% remaining battery detected forcing suspend
Just to circle back around. Due to the above upower output I really started to suspect hardware. I ended up checking the release iso, and subsequently a certain Microsoft OS. Both also saw the same issues. Lenovo is over-nighting me a new battery. Apparently the electronics in the battery died fantastically. Shame on me for suspecting our beloved OS. ** Changed in: linux (Ubuntu) Status: Confirmed => Invalid ** Changed in: upower (Ubuntu) Status: New => Invalid ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Dave Chiluk (chiluk) ** Changed in: upower (Ubuntu) Assignee: (unassigned) => Dave Chiluk (chiluk) ** Changed in: indicator-power (Ubuntu) Assignee: (unassigned) => Dave Chiluk (chiluk) -- 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/1588944 Title: Incorrect 0% remaining battery detected forcing suspend Status in indicator-power package in Ubuntu: Invalid Status in linux package in Ubuntu: Invalid Status in upower package in Ubuntu: Invalid Bug description: Ubuntu is detecting that my battery has depleted to low or 0% which results in the OS forcing suspend. Normally this would be correct behavior, but in my case the battery has closer to 90% of remaining battery left. I have experienced this with 4.4.0-22 and 4.4.0-23, and am currently running 4.4.0-21 to see if it reproduces there as well. I do have -proposed enabled so it's a bit hard to determine if this is the kernel or something higher up the stack. This does seem to be mildly reproducible. 4.4.0-23 being the most problematic kernel so far. Of course this is a relatively new laptop so this could be a hardware issue as well. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-21-generic 4.4.0-21.37 ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6 Uname: Linux 4.4.0-21-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: chiluk 2462 F pulseaudio CurrentDesktop: Unity Date: Fri Jun 3 14:07:17 2016 HibernationDevice: RESUME=UUID=4f4ea88e-642e-4be5-bdf0-bbc7f47f5628 InstallationDate: Installed on 2016-04-25 (38 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 04f2:b531 Chicony Electronics Co., Ltd Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: LENOVO 20FBCTO1WW ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-21-generic root=UUID=249f91bb-7789-41cc-9cc0-8ba25d7f55bb ro quiet splash pcie_aspm=force vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-4.4.0-21-generic N/A linux-backports-modules-4.4.0-21-generic N/A linux-firmware1.157 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/18/2016 dmi.bios.vendor: LENOVO dmi.bios.version: N1FET40W (1.14 ) dmi.board.asset.tag: Not Available dmi.board.name: 20FBCTO1WW dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN1FET40W(1.14):bd04/18/2016:svnLENOVO:pn20FBCTO1WW:pvrThinkPadX1Carbon4th:rvnLENOVO:rn20FBCTO1WW:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrNone: dmi.product.name: 20FBCTO1WW dmi.product.version: ThinkPad X1 Carbon 4th dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/indicator-power/+bug/1588944/+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 1588944] Re: Incorrect 0% remaining battery detected forcing suspend
Here's a log of me pulling power, and plugging it back in. ** Also affects: upower (Ubuntu) Importance: Undecided Status: New ** Attachment added: "upower.out" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1588944/+attachment/4679103/+files/upower.out -- 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/1588944 Title: Incorrect 0% remaining battery detected forcing suspend Status in indicator-power package in Ubuntu: New Status in linux package in Ubuntu: Confirmed Status in upower package in Ubuntu: New Bug description: Ubuntu is detecting that my battery has depleted to low or 0% which results in the OS forcing suspend. Normally this would be correct behavior, but in my case the battery has closer to 90% of remaining battery left. I have experienced this with 4.4.0-22 and 4.4.0-23, and am currently running 4.4.0-21 to see if it reproduces there as well. I do have -proposed enabled so it's a bit hard to determine if this is the kernel or something higher up the stack. This does seem to be mildly reproducible. 4.4.0-23 being the most problematic kernel so far. Of course this is a relatively new laptop so this could be a hardware issue as well. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-21-generic 4.4.0-21.37 ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6 Uname: Linux 4.4.0-21-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: chiluk 2462 F pulseaudio CurrentDesktop: Unity Date: Fri Jun 3 14:07:17 2016 HibernationDevice: RESUME=UUID=4f4ea88e-642e-4be5-bdf0-bbc7f47f5628 InstallationDate: Installed on 2016-04-25 (38 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 04f2:b531 Chicony Electronics Co., Ltd Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: LENOVO 20FBCTO1WW ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-21-generic root=UUID=249f91bb-7789-41cc-9cc0-8ba25d7f55bb ro quiet splash pcie_aspm=force vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-4.4.0-21-generic N/A linux-backports-modules-4.4.0-21-generic N/A linux-firmware1.157 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/18/2016 dmi.bios.vendor: LENOVO dmi.bios.version: N1FET40W (1.14 ) dmi.board.asset.tag: Not Available dmi.board.name: 20FBCTO1WW dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN1FET40W(1.14):bd04/18/2016:svnLENOVO:pn20FBCTO1WW:pvrThinkPadX1Carbon4th:rvnLENOVO:rn20FBCTO1WW:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrNone: dmi.product.name: 20FBCTO1WW dmi.product.version: ThinkPad X1 Carbon 4th dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/indicator-power/+bug/1588944/+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 1580272] Re: i915-bpo crashes on external hdmi input
Running 4.4.0-23-generic, I see the same errors as https://bugs.freedesktop.org/show_bug.cgi?id=89055 I see [ 1248.953987] PM: early resume of devices complete after 6.795 msecs [ 1248.956059] rtc_cmos 00:02: System wakeup disabled by ACPI [ 1249.227488] usb 1-8: reset high-speed USB device number 3 using xhci_hcd [ 1249.393400] [ cut here ] [ 1249.393456] WARNING: CPU: 2 PID: 5122 at /build/linux-L7iE5S/linux-4.4.0/ubuntu/i915/intel_pm.c:3586 skl_update_other_pipe_wm+0x16c/0x180 [i915_bpo]() [ 1249.393458] WARN_ON(!wm_changed) [ 1249.393514] Modules linked in: drbg ansi_cprng ctr ccm xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables overlay bnep snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_codec_generic joydev binfmt_misc arc4 acer_wmi sparse_keymap nls_iso8859_1 intel_rapl snd_soc_skl x86_pkg_temp_thermal uvcvideo intel_powerclamp coretemp videobuf2_vmalloc snd_soc_skl_ipc videobuf2_memops crct10dif_pclmul videobuf2_v4l2 snd_hda_ext_core crc32_pclmul videobuf2_core snd_soc_sst_ipc v4l2_common snd_soc_sst_dsp videodev aesni_intel snd_soc_core media snd_compress ac97_bus snd_pcm_dmaengine [ 1249.393565] dw_dmac_core aes_x86_64 lrw gf128mul snd_hda_intel glue_helper ablk_helper cryptd snd_hda_codec snd_hda_core snd_hwdep iwlmvm snd_pcm input_leds mac80211 serio_raw btusb thinkpad_acpi btrtl btbcm btintel nvram bluetooth iwlwifi snd_seq_midi snd_seq_midi_event cfg80211 snd_rawmidi mei_me mei snd_seq shpchp snd_seq_device snd_timer snd soundcore mac_hid tpm_crb kvm_intel kvm irqbypass parport_pc ppdev sunrpc lp parport autofs4 i915_bpo intel_ips i2c_algo_bit drm_kms_helper syscopyarea sysfillrect psmouse sysimgblt fb_sys_fops drm nvme wmi video fjes [ 1249.393570] CPU: 2 PID: 5122 Comm: kworker/u16:12 Tainted: G U W 4.4.0-23-generic #41-Ubuntu [ 1249.393572] Hardware name: LENOVO 20FBCTO1WW/20FBCTO1WW, BIOS N1FET40W (1.14 ) 04/18/2016 [ 1249.393581] Workqueue: events_unbound async_run_entry_fn [ 1249.393587] 0286 280ea446 88040bb6f900 813eaa03 [ 1249.393590] 88040bb6f948 c0224c98 88040bb6f938 810810d2 [ 1249.393594] 8804093ff000 8804086f9d9c 8804093f9000 88040e53eb78 [ 1249.393595] Call Trace: [ 1249.393605] [] dump_stack+0x63/0x90 [ 1249.393611] [] warn_slowpath_common+0x82/0xc0 [ 1249.393615] [] warn_slowpath_fmt+0x5c/0x80 [ 1249.393656] [] skl_update_other_pipe_wm+0x16c/0x180 [i915_bpo] [ 1249.393693] [] skl_update_wm+0x186/0x5f0 [i915_bpo] [ 1249.393749] [] ? intel_ddi_enable_transcoder_func+0x17f/0x260 [i915_bpo] [ 1249.393786] [] intel_update_watermarks+0x1e/0x30 [i915_bpo] [ 1249.393841] [] haswell_crtc_enable+0x321/0x8c0 [i915_bpo] [ 1249.393893] [] ? intel_finish_crtc_commit+0xe/0x10 [i915_bpo] [ 1249.393911] [] ? drm_atomic_helper_commit_planes_on_crtc+0x154/0x270 [drm_kms_helper] [ 1249.393963] [] intel_atomic_commit+0x5f8/0xdc0 [i915_bpo] [ 1249.394009] [] ? drm_atomic_check_only+0x18e/0x590 [drm] [ 1249.394047] [] drm_atomic_commit+0x37/0x60 [drm] [ 1249.394099] [] intel_display_resume+0xc4/0x160 [i915_bpo] [ 1249.394128] [] i915_drm_resume+0xdd/0x160 [i915_bpo] [ 1249.394157] [] i915_pm_resume+0x25/0x30 [i915_bpo] [ 1249.394162] [] pci_pm_resume+0x64/0xa0 [ 1249.394164] [] ? pci_pm_thaw+0x90/0x90 [ 1249.394171] [] dpm_run_callback+0x4e/0x140 [ 1249.394176] [] device_resume+0xd3/0x1f0 [ 1249.394181] [] async_resume+0x1d/0x50 [ 1249.394186] [] async_run_entry_fn+0x48/0x150 [ 1249.394191] [] process_one_work+0x165/0x480 [ 1249.394196] [] worker_thread+0x4b/0x4c0 [ 1249.394200] [] ? process_one_work+0x480/0x480 [ 1249.394203] [] kthread+0xd8/0xf0 [ 1249.394207] [] ? kthread_create_on_node+0x1e0/0x1e0 [ 1249.394212] [] ret_from_fork+0x3f/0x70 [ 1249.394215] [] ? kthread_create_on_node+0x1e0/0x1e0 [ 1249.394218] ---[ end trace 1135ec8b42e2923e ]--- -- 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/1580272 Title: i915-bpo crashes on external hdmi input Status in linux package in Ubuntu: Confirmed Bug description: This issue happens when plugging in an external HDMI projector in mirrored mode. To reproduce this issue: 1) Plug in external HDMI monitor 2) Set mirrored displays 3) Unplug HDMI 4) check dmesg for warnings -- ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-22-generic 4.4.0-22.39 ProcVersionSignature: Ubuntu 4.4.0-22.39-generic 4.4.8 Uname: Linux 4.4.0-22-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USERPID
[Kernel-packages] [Bug 1588944] Re: Incorrect 0% remaining battery detected forcing suspend
So as I haven't really messed with power monitoring, I discovered upower --monitor-detail. After having been unplugged for a few minutes the below state change occurred. I'm open to advice on how to continue looking into this. My first guess is to open the upower sources to see where it's getting this information. I'm guessing it will be dbus. How dbus is monitoring it though is anyone's guess. chiluk@x1:~$ sudo upower --monitor-detail [sudo] password for chiluk: Monitoring activity from the power daemon. Press Ctrl+C to cancel. [13:31:28.826] device changed: /org/freedesktop/UPower/devices/battery_BAT0 native-path: BAT0 power supply: yes updated: Tue 07 Jun 2016 01:31:28 PM CDT (0 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable:yes state: empty warning-level: none energy: 0 Wh energy-empty:0 Wh energy-full: 0 Wh energy-full-design: 0 Wh energy-rate: 0 W percentage: 0% capacity:100% icon-name: 'battery-empty-symbolic' -- 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/1588944 Title: Incorrect 0% remaining battery detected forcing suspend Status in indicator-power package in Ubuntu: New Status in linux package in Ubuntu: Confirmed Bug description: Ubuntu is detecting that my battery has depleted to low or 0% which results in the OS forcing suspend. Normally this would be correct behavior, but in my case the battery has closer to 90% of remaining battery left. I have experienced this with 4.4.0-22 and 4.4.0-23, and am currently running 4.4.0-21 to see if it reproduces there as well. I do have -proposed enabled so it's a bit hard to determine if this is the kernel or something higher up the stack. This does seem to be mildly reproducible. 4.4.0-23 being the most problematic kernel so far. Of course this is a relatively new laptop so this could be a hardware issue as well. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-21-generic 4.4.0-21.37 ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6 Uname: Linux 4.4.0-21-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: chiluk 2462 F pulseaudio CurrentDesktop: Unity Date: Fri Jun 3 14:07:17 2016 HibernationDevice: RESUME=UUID=4f4ea88e-642e-4be5-bdf0-bbc7f47f5628 InstallationDate: Installed on 2016-04-25 (38 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 04f2:b531 Chicony Electronics Co., Ltd Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: LENOVO 20FBCTO1WW ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-21-generic root=UUID=249f91bb-7789-41cc-9cc0-8ba25d7f55bb ro quiet splash pcie_aspm=force vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-4.4.0-21-generic N/A linux-backports-modules-4.4.0-21-generic N/A linux-firmware1.157 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/18/2016 dmi.bios.vendor: LENOVO dmi.bios.version: N1FET40W (1.14 ) dmi.board.asset.tag: Not Available dmi.board.name: 20FBCTO1WW dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN1FET40W(1.14):bd04/18/2016:svnLENOVO:pn20FBCTO1WW:pvrThinkPadX1Carbon4th:rvnLENOVO:rn20FBCTO1WW:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrNone: dmi.product.name: 20FBCTO1WW dmi.product.version: ThinkPad X1 Carbon 4th dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/indicator-power/+bug/1588944/+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
