[Kernel-packages] [Bug 1949286] Re: [MIR]: Include dwarves-dfsg-hwe package into Bionic and Focal
We don't, like we've spoken on IRC. Thanks a lot for the information. I missed the SRUs and I'm very glad they were done. -- 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/1949286 Title: [MIR]: Include dwarves-dfsg-hwe package into Bionic and Focal Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Incomplete Status in linux source package in Focal: Incomplete Bug description: This is a follow-on request of bug: HWE kernels should support eBPF CO-RE https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1926330 [Availability] - Package is already available in all Ubuntu versions. - This is a backported version (Impish) to Bionic and Focal [Rationale] - Current package dwarves-dfsg is old in Ubuntu Bionic and Focal. - HWE kernel compilation needs recent "pahole" binary to encode BTF[1] information. - After talking to SRU team members, updating dwarves-dfsg seemed risky. - Creating a new package containing only the new "pahole" tool binary is the best option. - Kernel HWE compilations will need to use this package, so it has to be in main repository (as kernels builds depend on main only). [Security] - This package is already stable and exists in Ubuntu. [Quality assurance] - This package is already stable and exists in Ubuntu. [Dependencies] - Same dependencies as dwarves-dfsg package (already satisfied). [Standards compliance] - This package is already stable and exists in Ubuntu. [Maintenance] - SRUs for dwarves-dfsg package within Impish should be applied to this package as well. [Background information] Bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1926330 contains more information about why this is needed. I have been maintaining BTFHUB (https://github.com/aquasecurity/btfhub) in order to generate BTF files to each existing Ubuntu kernel but I feel that a simple change, like adding a recent pahole tool to the main archive in Bionic and Focal, is enough to resolve a VERY BIG problem for eBPF applications to run in HWE kernels in those Ubuntu versions. A very complete explanation on why BTF is needed for eBPF to be portable among different kernels currently exists at: https://github.com/aquasecurity/btfhub/tree/main/tools. Projects that would already benefit from this change: - Microsoft: Sysmon Tools for Linux - Microsoft: Inspektor Gadge - Elastic: They're working together with us upstream - Aqua Security: libbpfgo & tracee-ebpf - All BCC libbpf-tools and many more. [1] https://www.kernel.org/doc/html/latest/bpf/btf.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1949286/+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 1926330] Re: HWE kernels should support eBPF CO-RE
** Changed in: dwarves-dfsg (Ubuntu Bionic) Status: Won't Fix => Confirmed ** Changed in: linux (Ubuntu Bionic) Status: Won't Fix => 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/1926330 Title: HWE kernels should support eBPF CO-RE Status in dwarves-dfsg package in Ubuntu: Fix Released Status in linux package in Ubuntu: Fix Released Status in dwarves-dfsg source package in Bionic: Confirmed Status in linux source package in Bionic: Confirmed Status in dwarves-dfsg source package in Focal: Confirmed Status in linux source package in Focal: Confirmed Status in dwarves-dfsg source package in Groovy: Fix Released Status in linux source package in Groovy: Fix Released Bug description: I had recent discussion with kernel team regarding support or not BTF in HWE kernels (Bionic and Focal). Having CONFIG_DEBUG_INFO_BTF option enabled for HWE kernels (v4.4 and v.4.8) would allow eBPF based code (powered by libbpf or not) to be RO.CE (https://github.com/rafaeldtinoco/portablebpf for more information). By allowing runtime relocations, using provided BTF, libbpf binaries might end up running, without modifications, in different kernel versions (from Bionic HWE v5.4 kernel to Hirsute v5.11). A good example would be to support tools such as: https://github.com/aquasecurity/tracee/discussions/713#discussioncomment-665641 An ebpf powered backend for a containers security solution. Considering: $ rmadisonb dwarves dwarves | 1.9-1 | precise/universe | amd64 dwarves | 1.10-2 | trusty | amd64 dwarves | 1.10-2.1 | xenial/universe | amd64 dwarves | 1.10-2.1build1 | bionic/universe | amd64 dwarves | 1.15-2 | focal/universe | amd64 dwarves | 1.17-1 | groovy/universe | amd64 dwarves | 1.20-1 | hirsute/universe | amd64 dwarves | 1.20-1 | impish/universe | amd64 And the fact that the 'pahole' binary, from dwarves package, is the one to blame, not to have CONFIG_DEBUG_INFO_BTF available, for this bug to be solved we would have to provide a backport of dwarves (at least 1.17-1) to Bionic and Focal. It could have another name (not to mess with original dwarves package and its dependencies) and it is unclear if it needs to be in [main] or [universe]. Question: Would have dwarves backported in -backports be enough for Bionic and Focal HWE kernels compilation to have CONFIG_DEBUG_INFO_BTF enabled ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dwarves-dfsg/+bug/1926330/+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 1949286] Re: [MIR]: Include dwarves-dfsg-hwe package into Bionic and Focal
After this MIR, the kernel HWE source code will have to use "pahole-btf" tool to do the BTF encoding in the HWE kernel builds from then on. -- 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/1949286 Title: [MIR]: Include dwarves-dfsg-hwe package into Bionic and Focal Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Confirmed Status in linux source package in Focal: Confirmed Bug description: This is a follow-on request of bug: HWE kernels should support eBPF CO-RE https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1926330 [Availability] - Package is already available in all Ubuntu versions. - This is a backported version (Impish) to Bionic and Focal [Rationale] - Current package dwarves-dfsg is old in Ubuntu Bionic and Focal. - HWE kernel compilation needs recent "pahole" binary to encode BTF[1] information. - After talking to SRU team members, updating dwarves-dfsg seemed risky. - Creating a new package containing only the new "pahole" tool binary is the best option. - Kernel HWE compilations will need to use this package, so it has to be in main repository (as kernels builds depend on main only). [Security] - This package is already stable and exists in Ubuntu. [Quality assurance] - This package is already stable and exists in Ubuntu. [Dependencies] - Same dependencies as dwarves-dfsg package (already satisfied). [Standards compliance] - This package is already stable and exists in Ubuntu. [Maintenance] - SRUs for dwarves-dfsg package within Impish should be applied to this package as well. [Background information] Bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1926330 contains more information about why this is needed. I have been maintaining BTFHUB (https://github.com/aquasecurity/btfhub) in order to generate BTF files to each existing Ubuntu kernel but I feel that a simple change, like adding a recent pahole tool to the main archive in Bionic and Focal, is enough to resolve a VERY BIG problem for eBPF applications to run in HWE kernels in those Ubuntu versions. A very complete explanation on why BTF is needed for eBPF to be portable among different kernels currently exists at: https://github.com/aquasecurity/btfhub/tree/main/tools. Projects that would already benefit from this change: - Microsoft: Sysmon Tools for Linux - Microsoft: Inspektor Gadge - Elastic: They're working together with us upstream - Aqua Security: libbpfgo & tracee-ebpf - All BCC libbpf-tools and many more. [1] https://www.kernel.org/doc/html/latest/bpf/btf.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1949286/+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 1926330] Re: HWE kernels should support eBPF CO-RE
I have placed a MIR for "pahole-btf" package (a backport of Impish's dwarves-dfsg package to Bionic and Focal) at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1949286. This way, the kernel builds may depend on "pahole-btf" binary package, from main, and finally include BTF debug information into Bionic and Focal HWE 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/1926330 Title: HWE kernels should support eBPF CO-RE Status in dwarves-dfsg package in Ubuntu: Fix Released Status in linux package in Ubuntu: Fix Released Status in dwarves-dfsg source package in Bionic: Won't Fix Status in linux source package in Bionic: Won't Fix Status in dwarves-dfsg source package in Focal: Confirmed Status in linux source package in Focal: Confirmed Status in dwarves-dfsg source package in Groovy: Fix Released Status in linux source package in Groovy: Fix Released Bug description: I had recent discussion with kernel team regarding support or not BTF in HWE kernels (Bionic and Focal). Having CONFIG_DEBUG_INFO_BTF option enabled for HWE kernels (v4.4 and v.4.8) would allow eBPF based code (powered by libbpf or not) to be RO.CE (https://github.com/rafaeldtinoco/portablebpf for more information). By allowing runtime relocations, using provided BTF, libbpf binaries might end up running, without modifications, in different kernel versions (from Bionic HWE v5.4 kernel to Hirsute v5.11). A good example would be to support tools such as: https://github.com/aquasecurity/tracee/discussions/713#discussioncomment-665641 An ebpf powered backend for a containers security solution. Considering: $ rmadisonb dwarves dwarves | 1.9-1 | precise/universe | amd64 dwarves | 1.10-2 | trusty | amd64 dwarves | 1.10-2.1 | xenial/universe | amd64 dwarves | 1.10-2.1build1 | bionic/universe | amd64 dwarves | 1.15-2 | focal/universe | amd64 dwarves | 1.17-1 | groovy/universe | amd64 dwarves | 1.20-1 | hirsute/universe | amd64 dwarves | 1.20-1 | impish/universe | amd64 And the fact that the 'pahole' binary, from dwarves package, is the one to blame, not to have CONFIG_DEBUG_INFO_BTF available, for this bug to be solved we would have to provide a backport of dwarves (at least 1.17-1) to Bionic and Focal. It could have another name (not to mess with original dwarves package and its dependencies) and it is unclear if it needs to be in [main] or [universe]. Question: Would have dwarves backported in -backports be enough for Bionic and Focal HWE kernels compilation to have CONFIG_DEBUG_INFO_BTF enabled ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dwarves-dfsg/+bug/1926330/+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 1949286] Re: [MIR]: Include dwarves-dfsg-hwe package into Bionic and Focal
The proposed package is at: https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/pahole-btf -- 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/1949286 Title: [MIR]: Include dwarves-dfsg-hwe package into Bionic and Focal Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Confirmed Status in linux source package in Focal: Confirmed Bug description: This is a follow-on request of bug: HWE kernels should support eBPF CO-RE https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1926330 [Availability] - Package is already available in all Ubuntu versions. - This is a backported version (Impish) to Bionic and Focal [Rationale] - Current package dwarves-dfsg is old in Ubuntu Bionic and Focal. - HWE kernel compilation needs recent "pahole" binary to encode BTF[1] information. - After talking to SRU team members, updating dwarves-dfsg seemed risky. - Creating a new package containing only the new "pahole" tool binary is the best option. - Kernel HWE compilations will need to use this package, so it has to be in main repository (as kernels builds depend on main only). [Security] - This package is already stable and exists in Ubuntu. [Quality assurance] - This package is already stable and exists in Ubuntu. [Dependencies] - Same dependencies as dwarves-dfsg package (already satisfied). [Standards compliance] - This package is already stable and exists in Ubuntu. [Maintenance] - SRUs for dwarves-dfsg package within Impish should be applied to this package as well. [Background information] Bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1926330 contains more information about why this is needed. I have been maintaining BTFHUB (https://github.com/aquasecurity/btfhub) in order to generate BTF files to each existing Ubuntu kernel but I feel that a simple change, like adding a recent pahole tool to the main archive in Bionic and Focal, is enough to resolve a VERY BIG problem for eBPF applications to run in HWE kernels in those Ubuntu versions. A very complete explanation on why BTF is needed for eBPF to be portable among different kernels currently exists at: https://github.com/aquasecurity/btfhub/tree/main/tools. Projects that would already benefit from this change: - Microsoft: Sysmon Tools for Linux - Microsoft: Inspektor Gadge - Elastic: They're working together with us upstream - Aqua Security: libbpfgo & tracee-ebpf - All BCC libbpf-tools and many more. [1] https://www.kernel.org/doc/html/latest/bpf/btf.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1949286/+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 1949286] Re: [MIR]: Include dwarves-dfsg-hwe package into Bionic and Focal
** Description changed: This is a follow-on request of bug: HWE kernels should support eBPF CO-RE https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1926330 [Availability] - Package is already available in all Ubuntu versions. - This is a backported version (Impish) to Bionic and Focal [Rationale] - - Current package dwarves-dfsg is old in Ubuntu Bionic and Focal - - HWE kernel compilation needs recent "pahole" binary to encode BTF[1] information - - After talking to SRU team members, updating dwarves-dfsg seemed risky - - Creating a new package for a more recent version of dwarves seems appropriate + - Current package dwarves-dfsg is old in Ubuntu Bionic and Focal. + - HWE kernel compilation needs recent "pahole" binary to encode BTF[1] information. + - After talking to SRU team members, updating dwarves-dfsg seemed risky. + - Creating a new package containing only the new "pahole" tool binary is the best option. + - Kernel HWE compilations will need to use this package, so it has to be in main repository (as kernels builds depend on main only). [Security] + - This package is already stable and exists in Ubuntu. + + [Quality assurance] - [UI standards] + - This package is already stable and exists in Ubuntu. [Dependencies] + - Same dependencies as dwarves-dfsg package (already satisfied). + [Standards compliance] + + - This package is already stable and exists in Ubuntu. [Maintenance] + - SRUs for dwarves-dfsg package within Impish should be applied to this + package as well. + [Background information] + Bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1926330 + contains more information about why this is needed. + + I have been maintaining BTFHUB (https://github.com/aquasecurity/btfhub) + in order to generate BTF files to each existing Ubuntu kernel but I feel + that a simple change, like adding a recent pahole tool to the main + archive in Bionic and Focal, is enough to resolve a VERY BIG problem for + eBPF applications to run in HWE kernels in those Ubuntu versions. + + A very complete explanation on why BTF is needed for eBPF to be portable + among different kernels currently exists at: + https://github.com/aquasecurity/btfhub/tree/main/tools. + + Projects that would already benefit from this change: + + - Microsoft: Sysmon Tools for Linux + - Microsoft: Inspektor Gadge + - Elastic: They're working together with us upstream + - Aqua Security: libbpfgo & tracee-ebpf + - All BCC libbpf-tools + + and many more. [1] https://www.kernel.org/doc/html/latest/bpf/btf.html ** Also affects: linux (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: linux (Ubuntu) Status: New => Fix Released ** Changed in: linux (Ubuntu Bionic) Importance: Undecided => High ** Changed in: linux (Ubuntu Focal) Importance: Undecided => High ** Changed in: linux (Ubuntu Bionic) Status: New => Confirmed ** Changed in: linux (Ubuntu Focal) 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/1949286 Title: [MIR]: Include dwarves-dfsg-hwe package into Bionic and Focal Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Confirmed Status in linux source package in Focal: Confirmed Bug description: This is a follow-on request of bug: HWE kernels should support eBPF CO-RE https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1926330 [Availability] - Package is already available in all Ubuntu versions. - This is a backported version (Impish) to Bionic and Focal [Rationale] - Current package dwarves-dfsg is old in Ubuntu Bionic and Focal. - HWE kernel compilation needs recent "pahole" binary to encode BTF[1] information. - After talking to SRU team members, updating dwarves-dfsg seemed risky. - Creating a new package containing only the new "pahole" tool binary is the best option. - Kernel HWE compilations will need to use this package, so it has to be in main repository (as kernels builds depend on main only). [Security] - This package is already stable and exists in Ubuntu. [Quality assurance] - This package is already stable and exists in Ubuntu. [Dependencies] - Same dependencies as dwarves-dfsg package (already satisfied). [Standards compliance] - This package is already stable and exists in Ubuntu. [Maintenance] - SRUs for dwarves-dfsg package within Impish should be applied to this package as well. [Background information] Bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1926330 contains more information about why this is needed. I have been maintaining BTFHUB (https://github.com/aquasecurity/btfhub) in order to generate BTF files
[Kernel-packages] [Bug 1949286] [NEW] [MIR]: Include dwarves-dfsg-hwe package into Bionic and Focal
Public bug reported: This is a follow-on request of bug: HWE kernels should support eBPF CO-RE https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1926330 [Availability] - Package is already available in all Ubuntu versions. - This is a backported version (Impish) to Bionic and Focal [Rationale] - Current package dwarves-dfsg is old in Ubuntu Bionic and Focal. - HWE kernel compilation needs recent "pahole" binary to encode BTF[1] information. - After talking to SRU team members, updating dwarves-dfsg seemed risky. - Creating a new package containing only the new "pahole" tool binary is the best option. - Kernel HWE compilations will need to use this package, so it has to be in main repository (as kernels builds depend on main only). [Security] - This package is already stable and exists in Ubuntu. [Quality assurance] - This package is already stable and exists in Ubuntu. [Dependencies] - Same dependencies as dwarves-dfsg package (already satisfied). [Standards compliance] - This package is already stable and exists in Ubuntu. [Maintenance] - SRUs for dwarves-dfsg package within Impish should be applied to this package as well. [Background information] Bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1926330 contains more information about why this is needed. I have been maintaining BTFHUB (https://github.com/aquasecurity/btfhub) in order to generate BTF files to each existing Ubuntu kernel but I feel that a simple change, like adding a recent pahole tool to the main archive in Bionic and Focal, is enough to resolve a VERY BIG problem for eBPF applications to run in HWE kernels in those Ubuntu versions. A very complete explanation on why BTF is needed for eBPF to be portable among different kernels currently exists at: https://github.com/aquasecurity/btfhub/tree/main/tools. Projects that would already benefit from this change: - Microsoft: Sysmon Tools for Linux - Microsoft: Inspektor Gadge - Elastic: They're working together with us upstream - Aqua Security: libbpfgo & tracee-ebpf - All BCC libbpf-tools and many more. [1] https://www.kernel.org/doc/html/latest/bpf/btf.html ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Affects: linux (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/1949286 Title: [MIR]: Include dwarves-dfsg-hwe package into Bionic and Focal Status in linux package in Ubuntu: New Status in linux source package in Bionic: New Status in linux source package in Focal: New Bug description: This is a follow-on request of bug: HWE kernels should support eBPF CO-RE https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1926330 [Availability] - Package is already available in all Ubuntu versions. - This is a backported version (Impish) to Bionic and Focal [Rationale] - Current package dwarves-dfsg is old in Ubuntu Bionic and Focal. - HWE kernel compilation needs recent "pahole" binary to encode BTF[1] information. - After talking to SRU team members, updating dwarves-dfsg seemed risky. - Creating a new package containing only the new "pahole" tool binary is the best option. - Kernel HWE compilations will need to use this package, so it has to be in main repository (as kernels builds depend on main only). [Security] - This package is already stable and exists in Ubuntu. [Quality assurance] - This package is already stable and exists in Ubuntu. [Dependencies] - Same dependencies as dwarves-dfsg package (already satisfied). [Standards compliance] - This package is already stable and exists in Ubuntu. [Maintenance] - SRUs for dwarves-dfsg package within Impish should be applied to this package as well. [Background information] Bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1926330 contains more information about why this is needed. I have been maintaining BTFHUB (https://github.com/aquasecurity/btfhub) in order to generate BTF files to each existing Ubuntu kernel but I feel that a simple change, like adding a recent pahole tool to the main archive in Bionic and Focal, is enough to resolve a VERY BIG problem for eBPF applications to run in HWE kernels in those Ubuntu versions. A very complete explanation on why BTF is needed for eBPF to be portable among different kernels currently exists at: https://github.com/aquasecurity/btfhub/tree/main/tools. Projects that would already benefit from this change: - Microsoft: Sysmon Tools for Linux - Microsoft: Inspektor Gadge - Elastic: They're working together with us upstream - Aqua Security: libbpfgo & tracee-ebpf - All BCC libbpf-tools and many more. [1]
[Kernel-packages] [Bug 1926330] Re: HWE kernels should enable BTF support to enable eBPF CO-RE support
** Summary changed: - HWE kernels should enable BTF support to enable eBPF RO.CE support + HWE kernels should enable BTF support to enable eBPF CO-RE support ** Summary changed: - HWE kernels should enable BTF support to enable eBPF CO-RE support + HWE kernels should support eBPF CO-RE -- 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/1926330 Title: HWE kernels should support eBPF CO-RE Status in dwarves-dfsg package in Ubuntu: Fix Released Status in linux package in Ubuntu: Fix Released Status in dwarves-dfsg source package in Bionic: Won't Fix Status in linux source package in Bionic: Won't Fix Status in dwarves-dfsg source package in Focal: Confirmed Status in linux source package in Focal: Confirmed Status in dwarves-dfsg source package in Groovy: Fix Released Status in linux source package in Groovy: Fix Released Bug description: I had recent discussion with kernel team regarding support or not BTF in HWE kernels (Bionic and Focal). Having CONFIG_DEBUG_INFO_BTF option enabled for HWE kernels (v4.4 and v.4.8) would allow eBPF based code (powered by libbpf or not) to be RO.CE (https://github.com/rafaeldtinoco/portablebpf for more information). By allowing runtime relocations, using provided BTF, libbpf binaries might end up running, without modifications, in different kernel versions (from Bionic HWE v5.4 kernel to Hirsute v5.11). A good example would be to support tools such as: https://github.com/aquasecurity/tracee/discussions/713#discussioncomment-665641 An ebpf powered backend for a containers security solution. Considering: $ rmadisonb dwarves dwarves | 1.9-1 | precise/universe | amd64 dwarves | 1.10-2 | trusty | amd64 dwarves | 1.10-2.1 | xenial/universe | amd64 dwarves | 1.10-2.1build1 | bionic/universe | amd64 dwarves | 1.15-2 | focal/universe | amd64 dwarves | 1.17-1 | groovy/universe | amd64 dwarves | 1.20-1 | hirsute/universe | amd64 dwarves | 1.20-1 | impish/universe | amd64 And the fact that the 'pahole' binary, from dwarves package, is the one to blame, not to have CONFIG_DEBUG_INFO_BTF available, for this bug to be solved we would have to provide a backport of dwarves (at least 1.17-1) to Bionic and Focal. It could have another name (not to mess with original dwarves package and its dependencies) and it is unclear if it needs to be in [main] or [universe]. Question: Would have dwarves backported in -backports be enough for Bionic and Focal HWE kernels compilation to have CONFIG_DEBUG_INFO_BTF enabled ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dwarves-dfsg/+bug/1926330/+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 1926330] Re: HWE kernels should enable BTF support to enable eBPF RO.CE support
** No longer affects: dwarves-dfsg (Ubuntu Hirsute) ** No longer affects: linux (Ubuntu Hirsute) -- 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/1926330 Title: HWE kernels should enable BTF support to enable eBPF RO.CE support Status in dwarves-dfsg package in Ubuntu: Fix Released Status in linux package in Ubuntu: Fix Released Status in dwarves-dfsg source package in Bionic: Won't Fix Status in linux source package in Bionic: Won't Fix Status in dwarves-dfsg source package in Focal: Confirmed Status in linux source package in Focal: Confirmed Status in dwarves-dfsg source package in Groovy: Fix Released Status in linux source package in Groovy: Fix Released Bug description: I had recent discussion with kernel team regarding support or not BTF in HWE kernels (Bionic and Focal). Having CONFIG_DEBUG_INFO_BTF option enabled for HWE kernels (v4.4 and v.4.8) would allow eBPF based code (powered by libbpf or not) to be RO.CE (https://github.com/rafaeldtinoco/portablebpf for more information). By allowing runtime relocations, using provided BTF, libbpf binaries might end up running, without modifications, in different kernel versions (from Bionic HWE v5.4 kernel to Hirsute v5.11). A good example would be to support tools such as: https://github.com/aquasecurity/tracee/discussions/713#discussioncomment-665641 An ebpf powered backend for a containers security solution. Considering: $ rmadisonb dwarves dwarves | 1.9-1 | precise/universe | amd64 dwarves | 1.10-2 | trusty | amd64 dwarves | 1.10-2.1 | xenial/universe | amd64 dwarves | 1.10-2.1build1 | bionic/universe | amd64 dwarves | 1.15-2 | focal/universe | amd64 dwarves | 1.17-1 | groovy/universe | amd64 dwarves | 1.20-1 | hirsute/universe | amd64 dwarves | 1.20-1 | impish/universe | amd64 And the fact that the 'pahole' binary, from dwarves package, is the one to blame, not to have CONFIG_DEBUG_INFO_BTF available, for this bug to be solved we would have to provide a backport of dwarves (at least 1.17-1) to Bionic and Focal. It could have another name (not to mess with original dwarves package and its dependencies) and it is unclear if it needs to be in [main] or [universe]. Question: Would have dwarves backported in -backports be enough for Bionic and Focal HWE kernels compilation to have CONFIG_DEBUG_INFO_BTF enabled ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dwarves-dfsg/+bug/1926330/+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 1926330] Re: HWE kernels should enable BTF support to enable eBPF RO.CE support
** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed ** Changed in: dwarves-dfsg (Ubuntu) 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/1926330 Title: HWE kernels should enable BTF support to enable eBPF RO.CE support Status in dwarves-dfsg package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Status in dwarves-dfsg source package in Bionic: Confirmed Status in linux source package in Bionic: Confirmed Status in dwarves-dfsg source package in Focal: Confirmed Status in linux source package in Focal: Confirmed Status in dwarves-dfsg source package in Groovy: Fix Released Status in linux source package in Groovy: Fix Released Bug description: I had recent discussion with kernel team regarding support or not BTF in HWE kernels (Bionic and Focal). Having CONFIG_DEBUG_INFO_BTF option enabled for HWE kernels (v4.4 and v.4.8) would allow eBPF based code (powered by libbpf or not) to be RO.CE (https://github.com/rafaeldtinoco/portablebpf for more information). By allowing runtime relocations, using provided BTF, libbpf binaries might end up running, without modifications, in different kernel versions (from Bionic HWE v5.4 kernel to Hirsute v5.11). A good example would be to support tools such as: https://github.com/aquasecurity/tracee/discussions/713#discussioncomment-665641 An ebpf powered backend for a containers security solution. Considering: $ rmadisonb dwarves dwarves | 1.9-1 | precise/universe | amd64 dwarves | 1.10-2 | trusty | amd64 dwarves | 1.10-2.1 | xenial/universe | amd64 dwarves | 1.10-2.1build1 | bionic/universe | amd64 dwarves | 1.15-2 | focal/universe | amd64 dwarves | 1.17-1 | groovy/universe | amd64 dwarves | 1.20-1 | hirsute/universe | amd64 dwarves | 1.20-1 | impish/universe | amd64 And the fact that the 'pahole' binary, from dwarves package, is the one to blame, not to have CONFIG_DEBUG_INFO_BTF available, for this bug to be solved we would have to provide a backport of dwarves (at least 1.17-1) to Bionic and Focal. It could have another name (not to mess with original dwarves package and its dependencies) and it is unclear if it needs to be in [main] or [universe]. Question: Would have dwarves backported in -backports be enough for Bionic and Focal HWE kernels compilation to have CONFIG_DEBUG_INFO_BTF enabled ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dwarves-dfsg/+bug/1926330/+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 1926330] [NEW] HWE kernels should enable BTF support to enable eBPF RO.CE support
Public bug reported: I had recent discussion with kernel team regarding support or not BTF in HWE kernels (Bionic and Focal). Having CONFIG_DEBUG_INFO_BTF option enabled for HWE kernels (v4.4 and v.4.8) would allow eBPF based code (powered by libbpf or not) to be RO.CE (https://github.com/rafaeldtinoco/portablebpf for more information). By allowing runtime relocations, using provided BTF, libbpf binaries might end up running, without modifications, in different kernel versions (from Bionic HWE v5.4 kernel to Hirsute v5.11). A good example would be to support tools such as: https://github.com/aquasecurity/tracee/discussions/713#discussioncomment-665641 An ebpf powered backend for a containers security solution. Considering: $ rmadisonb dwarves dwarves | 1.9-1 | precise/universe | amd64 dwarves | 1.10-2 | trusty | amd64 dwarves | 1.10-2.1 | xenial/universe | amd64 dwarves | 1.10-2.1build1 | bionic/universe | amd64 dwarves | 1.15-2 | focal/universe | amd64 dwarves | 1.17-1 | groovy/universe | amd64 dwarves | 1.20-1 | hirsute/universe | amd64 dwarves | 1.20-1 | impish/universe | amd64 And the fact that the 'pahole' binary, from dwarves package, is the one to blame, not to have CONFIG_DEBUG_INFO_BTF available, for this bug to be solved we would have to provide a backport of dwarves (at least 1.17-1) to Bionic and Focal. It could have another name (not to mess with original dwarves package and its dependencies) and it is unclear if it needs to be in [main] or [universe]. Question: Would have dwarves backported in -backports be enough for Bionic and Focal HWE kernels compilation to have CONFIG_DEBUG_INFO_BTF enabled ? ** Affects: dwarves-dfsg (Ubuntu) Importance: Undecided Status: New ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete ** Affects: dwarves-dfsg (Ubuntu Bionic) Importance: Undecided Status: Confirmed ** Affects: linux (Ubuntu Bionic) Importance: Undecided Status: Confirmed ** Affects: dwarves-dfsg (Ubuntu Focal) Importance: Undecided Status: Confirmed ** Affects: linux (Ubuntu Focal) Importance: Undecided Status: Confirmed ** Affects: dwarves-dfsg (Ubuntu Groovy) Importance: Undecided Status: Fix Released ** Affects: linux (Ubuntu Groovy) Importance: Undecided Status: Fix Released ** Also affects: linux (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Groovy) Status: New => Fix Committed ** Changed in: linux (Ubuntu Groovy) Status: Fix Committed => Fix Released ** Changed in: linux (Ubuntu Focal) Status: New => Confirmed ** Changed in: linux (Ubuntu Bionic) Status: New => Confirmed ** Summary changed: - HWE kernels should enable BTF support to enable new eBPF based code + HWE kernels should enable BTF support to enable eBPF RO.CE support ** Also affects: dwarves-dfsg (Ubuntu) Importance: Undecided Status: New ** Changed in: dwarves-dfsg (Ubuntu Groovy) Status: New => Fix Released ** Changed in: dwarves-dfsg (Ubuntu Focal) Status: New => Confirmed ** Changed in: dwarves-dfsg (Ubuntu Bionic) 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/1926330 Title: HWE kernels should enable BTF support to enable eBPF RO.CE support Status in dwarves-dfsg package in Ubuntu: New Status in linux package in Ubuntu: Incomplete Status in dwarves-dfsg source package in Bionic: Confirmed Status in linux source package in Bionic: Confirmed Status in dwarves-dfsg source package in Focal: Confirmed Status in linux source package in Focal: Confirmed Status in dwarves-dfsg source package in Groovy: Fix Released Status in linux source package in Groovy: Fix Released Bug description: I had recent discussion with kernel team regarding support or not BTF in HWE kernels (Bionic and Focal). Having CONFIG_DEBUG_INFO_BTF option enabled for HWE kernels (v4.4 and v.4.8) would allow eBPF based code (powered by libbpf or not) to be RO.CE (https://github.com/rafaeldtinoco/portablebpf for more information). By allowing runtime relocations, using provided BTF, libbpf binaries might end up running, without modifications, in different kernel versions (from Bionic HWE v5.4 kernel to Hirsute v5.11). A good example would be to support tools such as: https://github.com/aquasecurity/tracee/discussions/713#discussioncomment-665641 An ebpf powered backend for a containers security solution. Considering: $ rmadisonb dwarves dwarves | 1.9-1 | precise/universe | amd64
[Kernel-packages] [Bug 1913187] Re: iproute2 segfaults when filtering sockets
# verfication
$ dpkg -l iproute2 | grep ii
ii iproute2 4.15.0-2ubuntu1.3 amd64networking and traffic
control tools
$ ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1 && echo
worked
worked
good to migrate. thank you.
-rafaeldtinoco
** Tags removed: verification-needed verification-needed-bionic
** Tags added: verification-done verification-done-bionic
** Changed in: iproute2 (Ubuntu Bionic)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to iproute2 in Ubuntu.
Matching subscriptions: iproute2
https://bugs.launchpad.net/bugs/1913187
Title:
iproute2 segfaults when filtering sockets
Status in iproute2 package in Ubuntu:
Fix Released
Status in iproute2 source package in Bionic:
Fix Committed
Bug description:
[Impact]
* The ss tool crashes when a query returns no results (seg fault)
[Test Case]
* $ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst
127.0.0.1
Segmentation fault
* PPA with the fix:
https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1913187
[Where problems could occur]
* The ss tool is impacted and it has its code changed for the fix.
* The fix is a clean cherry-pick and straightforward (moving
declaration after a NULL check).
[Other Info]
When in Ubuntu Bionic, if one calls:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
tcp 00
127.0.0.1:58910 127.0.0.1:22
users:(("ssh",pid=11672,fd=3)) timer:(keepalive,119min,0)
it works. Just like when in Groovy:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
tcp 00
127.0.0.1:58908 127.0.0.1:22
users:(("ssh",pid=1488591,fd=3)) timer:(keepalive,119min,0)
but.. if there is nothing to show, in Bionic we get a segfault:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
Segmentation fault
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1913187/+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 1913187] Re: iproute2 segfaults when filtering sockets
$ git-ubuntu tag --upload
$ git describe
upload/4.15.0-2ubuntu1.3
$ git push pkg upload/4.15.0-2ubuntu1.3
Counting objects: 11, done.
Delta compression using up to 24 threads.
Compressing objects: 100% (11/11), done.
Writing objects: 100% (11/11), 2.07 KiB | 176.00 KiB/s, done.
Total 11 (delta 7), reused 0 (delta 0)
To ssh://git.launchpad.net/ubuntu/+source/iproute2
* [new tag] upload/4.15.0-2ubuntu1.3 -> upload/4.15.0-2ubuntu1.3
$ debdiff *.dsc | diffstat
changelog | 7 +++
patches/lp1913187-ss-fix-NULL-dereference-when-rendering.patch | 40
patches/series | 1 +
3 files changed, 48 insertions(+)
[rafaeldtinoco@iproute2issue ubuntu]$ dput ubuntu
./iproute2_4.15.0-2ubuntu1.3_source.changes
Checking signature on .changes
gpg: ./iproute2_4.15.0-2ubuntu1.3_source.changes: Valid signature from
A93E0E0AD83C0D0F
Checking signature on .dsc
gpg: ./iproute2_4.15.0-2ubuntu1.3.dsc: Valid signature from A93E0E0AD83C0D0F
Uploading to ubuntu (via ftp to upload.ubuntu.com):
Uploading iproute2_4.15.0-2ubuntu1.3.dsc: done.
Uploading iproute2_4.15.0-2ubuntu1.3.debian.tar.xz: done.
Uploading iproute2_4.15.0-2ubuntu1.3_source.buildinfo: done.
Uploading iproute2_4.15.0-2ubuntu1.3_source.changes: done.
Successfully uploaded packages.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to iproute2 in Ubuntu.
Matching subscriptions: iproute2
https://bugs.launchpad.net/bugs/1913187
Title:
iproute2 segfaults when filtering sockets
Status in iproute2 package in Ubuntu:
Fix Released
Status in iproute2 source package in Bionic:
Confirmed
Bug description:
[Impact]
* The ss tool crashes when a query returns no results (seg fault)
[Test Case]
* $ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst
127.0.0.1
Segmentation fault
* PPA with the fix:
https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1913187
[Where problems could occur]
* The ss tool is impacted and it has its code changed for the fix.
* The fix is a clean cherry-pick and straightforward (moving
declaration after a NULL check).
[Other Info]
When in Ubuntu Bionic, if one calls:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
tcp 00
127.0.0.1:58910 127.0.0.1:22
users:(("ssh",pid=11672,fd=3)) timer:(keepalive,119min,0)
it works. Just like when in Groovy:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
tcp 00
127.0.0.1:58908 127.0.0.1:22
users:(("ssh",pid=1488591,fd=3)) timer:(keepalive,119min,0)
but.. if there is nothing to show, in Bionic we get a segfault:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
Segmentation fault
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1913187/+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 1913187] Re: iproute2 segfaults when filtering sockets
MP:
https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/iproute2/+git/iproute2/+merge/396921
PPA: https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1913187
** Description changed:
+ [Impact]
+
+ * The ss tool crashes when a query returns no results (seg fault)
+
+ [Test Case]
+
+ * $ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst
127.0.0.1
+ Segmentation fault
+
+ [Where problems could occur]
+
+ * The ss tool is impacted and it has its code changed for the fix.
+
+ * The fix is a clean cherry-pick and straightforward (moving
+ declaration after a NULL check).
+
+ [Other Info]
+
When in Ubuntu Bionic, if one calls:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
tcp 00
127.0.0.1:58910 127.0.0.1:22
users:(("ssh",pid=11672,fd=3)) timer:(keepalive,119min,0)
it works. Just like when in Groovy:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
tcp 00
127.0.0.1:58908 127.0.0.1:22
users:(("ssh",pid=1488591,fd=3)) timer:(keepalive,119min,0)
but.. if there is nothing to show, in Bionic we get a segfault:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
Segmentation fault
** Description changed:
[Impact]
- * The ss tool crashes when a query returns no results (seg fault)
+ * The ss tool crashes when a query returns no results (seg fault)
[Test Case]
- * $ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst
127.0.0.1
- Segmentation fault
+ * $ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst
127.0.0.1
+ Segmentation fault
+
+ * PPA with the fix:
+ https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1913187
[Where problems could occur]
- * The ss tool is impacted and it has its code changed for the fix.
+ * The ss tool is impacted and it has its code changed for the fix.
- * The fix is a clean cherry-pick and straightforward (moving
+ * The fix is a clean cherry-pick and straightforward (moving
declaration after a NULL check).
[Other Info]
-
+
When in Ubuntu Bionic, if one calls:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
tcp 00
127.0.0.1:58910 127.0.0.1:22
users:(("ssh",pid=11672,fd=3)) timer:(keepalive,119min,0)
it works. Just like when in Groovy:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
tcp 00
127.0.0.1:58908 127.0.0.1:22
users:(("ssh",pid=1488591,fd=3)) timer:(keepalive,119min,0)
but.. if there is nothing to show, in Bionic we get a segfault:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
Segmentation fault
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to iproute2 in Ubuntu.
Matching subscriptions: iproute2
https://bugs.launchpad.net/bugs/1913187
Title:
iproute2 segfaults when filtering sockets
Status in iproute2 package in Ubuntu:
Fix Released
Status in iproute2 source package in Bionic:
Confirmed
Bug description:
[Impact]
* The ss tool crashes when a query returns no results (seg fault)
[Test Case]
* $ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst
127.0.0.1
Segmentation fault
* PPA with the fix:
https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1913187
[Where problems could occur]
* The ss tool is impacted and it has its code changed for the fix.
* The fix is a clean cherry-pick and straightforward (moving
declaration after a NULL check).
[Other Info]
When in Ubuntu Bionic, if one calls:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
tcp 00
127.0.0.1:58910 127.0.0.1:22
users:(("ssh",pid=11672,fd=3)) timer:(keepalive,119min,0)
it works. Just like when in Groovy:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
tcp 00
127.0.0.1:58908 127.0.0.1:22
users:(("ssh",pid=1488591,fd=3)) timer:(keepalive,119min,0)
but.. if there is nothing to show, in Bionic we get a segfault:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
Segmentation fault
To manage notifications about this bug go to:
[Kernel-packages] [Bug 1913187] Re: iproute2 segfaults when filtering sockets
[rafaeldtinoco@iproute2issue iproute2]$ git unfixed
eb8559eff124221bfbafe934c4dbfe30f20604c0 is the first bad commit
commit eb8559eff124221bfbafe934c4dbfe30f20604c0
Author: Jean-Philippe Brucker
Date: Sat Mar 3 16:59:44 2018 +
ss: fix NULL dereference when rendering without header
When ss is invoked with the no-header flag, if the query doesn't return
any result, render() is called with 'buffer' uninitialized. This
currently leads to a segfault. Ensure that buffer is initialized before
rendering.
The bug can be triggered with: ss -H sport = 10
Signed-off-by: Jean-Philippe Brucker
Acked-by: Stefano Brivio
Signed-off-by: Stephen Hemminger
:04 04 bf8f626f1c0b85bd690dab60d4f74db292ac8e65
6174ebf0728edab46c62b713f6aee495eef81cb5 M misc
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to iproute2 in Ubuntu.
Matching subscriptions: iproute2
https://bugs.launchpad.net/bugs/1913187
Title:
iproute2 segfaults when filtering sockets
Status in iproute2 package in Ubuntu:
Fix Released
Status in iproute2 source package in Bionic:
Confirmed
Bug description:
When in Ubuntu Bionic, if one calls:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
tcp 00
127.0.0.1:58910 127.0.0.1:22
users:(("ssh",pid=11672,fd=3)) timer:(keepalive,119min,0)
it works. Just like when in Groovy:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
tcp 00
127.0.0.1:58908 127.0.0.1:22
users:(("ssh",pid=1488591,fd=3)) timer:(keepalive,119min,0)
but.. if there is nothing to show, in Bionic we get a segfault:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
Segmentation fault
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1913187/+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 1913187] Re: iproute2 segfaults when filtering sockets
It only affects Bionic:
[rafaeldtinoco@iproute2issue iproute2]$ git describe
eb8559eff124221bfbafe934c4dbfe30f20604c0
v4.15.0-103-geb8559ef
[rafaeldtinoco@iproute2issue ~]$ rmadison iproute2
iproute2 | 3.12.0-2 | trusty | source
iproute2 | 3.12.0-2ubuntu1.2 | trusty-updates | source
iproute2 | 4.3.0-1ubuntu3| xenial | source
iproute2 | 4.3.0-1ubuntu3.16.04.5| xenial-updates | source
iproute2 | 4.15.0-2ubuntu1 | bionic | source
iproute2 | 4.15.0-2ubuntu1.1 | bionic-security | source
iproute2 | 4.15.0-2ubuntu1.2 | bionic-updates | source
iproute2 | 4.18.0-1ubuntu2~ubuntu18.04.1 | bionic-backports | source
iproute2 | 5.5.0-1ubuntu1| focal| source
iproute2 | 5.7.0-1ubuntu1| groovy | source
iproute2 | 5.9.0-1ubuntu1| hirsute | source
iproute2 | 5.10.0-2ubuntu1 | hirsute-proposed | source
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to iproute2 in Ubuntu.
Matching subscriptions: iproute2
https://bugs.launchpad.net/bugs/1913187
Title:
iproute2 segfaults when filtering sockets
Status in iproute2 package in Ubuntu:
Fix Released
Status in iproute2 source package in Bionic:
Confirmed
Bug description:
When in Ubuntu Bionic, if one calls:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
tcp 00
127.0.0.1:58910 127.0.0.1:22
users:(("ssh",pid=11672,fd=3)) timer:(keepalive,119min,0)
it works. Just like when in Groovy:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
tcp 00
127.0.0.1:58908 127.0.0.1:22
users:(("ssh",pid=1488591,fd=3)) timer:(keepalive,119min,0)
but.. if there is nothing to show, in Bionic we get a segfault:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
Segmentation fault
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1913187/+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 1913187] Re: iproute2 segfaults when filtering sockets
workaround:
sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst
127.0.0.1 | cat -
by not trying to control terminal WIDTH, segfault does not occur.
** Changed in: iproute2 (Ubuntu Bionic)
Importance: Undecided => Low
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to iproute2 in Ubuntu.
Matching subscriptions: iproute2
https://bugs.launchpad.net/bugs/1913187
Title:
iproute2 segfaults when filtering sockets
Status in iproute2 package in Ubuntu:
Fix Released
Status in iproute2 source package in Bionic:
Confirmed
Bug description:
When in Ubuntu Bionic, if one calls:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
tcp 00
127.0.0.1:58910 127.0.0.1:22
users:(("ssh",pid=11672,fd=3)) timer:(keepalive,119min,0)
it works. Just like when in Groovy:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
tcp 00
127.0.0.1:58908 127.0.0.1:22
users:(("ssh",pid=1488591,fd=3)) timer:(keepalive,119min,0)
but.. if there is nothing to show, in Bionic we get a segfault:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
Segmentation fault
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1913187/+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 1913187] Re: iproute2 segfaults when filtering sockets
Issues comes from:
(gdb) bt
#0 render (screen_width=144) at ss.c:1204
#1 main (argc=, argv=) at ss.c:4974
render (screen_width=144) at ss.c:1204
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to iproute2 in Ubuntu.
Matching subscriptions: iproute2
https://bugs.launchpad.net/bugs/1913187
Title:
iproute2 segfaults when filtering sockets
Status in iproute2 package in Ubuntu:
Fix Released
Status in iproute2 source package in Bionic:
Confirmed
Bug description:
When in Ubuntu Bionic, if one calls:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
tcp 00
127.0.0.1:58910 127.0.0.1:22
users:(("ssh",pid=11672,fd=3)) timer:(keepalive,119min,0)
it works. Just like when in Groovy:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
tcp 00
127.0.0.1:58908 127.0.0.1:22
users:(("ssh",pid=1488591,fd=3)) timer:(keepalive,119min,0)
but.. if there is nothing to show, in Bionic we get a segfault:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
Segmentation fault
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1913187/+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 1913187] [NEW] iproute2 segfaults when filtering sockets
Public bug reported:
When in Ubuntu Bionic, if one calls:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
tcp 00
127.0.0.1:58910 127.0.0.1:22
users:(("ssh",pid=11672,fd=3)) timer:(keepalive,119min,0)
it works. Just like when in Groovy:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
tcp 00
127.0.0.1:58908 127.0.0.1:22
users:(("ssh",pid=1488591,fd=3)) timer:(keepalive,119min,0)
but.. if there is nothing to show, in Bionic we get a segfault:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
Segmentation fault
** Affects: iproute2 (Ubuntu)
Importance: Undecided
Status: Fix Released
** Affects: iproute2 (Ubuntu Bionic)
Importance: Undecided
Assignee: Rafael David Tinoco (rafaeldtinoco)
Status: Confirmed
** Changed in: iproute2 (Ubuntu)
Status: New => Confirmed
** Also affects: iproute2 (Ubuntu Bionic)
Importance: Undecided
Status: New
** Changed in: iproute2 (Ubuntu Bionic)
Status: New => Confirmed
** Changed in: iproute2 (Ubuntu)
Status: Confirmed => Fix Released
** Changed in: iproute2 (Ubuntu Bionic)
Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to iproute2 in Ubuntu.
Matching subscriptions: iproute2
https://bugs.launchpad.net/bugs/1913187
Title:
iproute2 segfaults when filtering sockets
Status in iproute2 package in Ubuntu:
Fix Released
Status in iproute2 source package in Bionic:
Confirmed
Bug description:
When in Ubuntu Bionic, if one calls:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
tcp 00
127.0.0.1:58910 127.0.0.1:22
users:(("ssh",pid=11672,fd=3)) timer:(keepalive,119min,0)
it works. Just like when in Groovy:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
tcp 00
127.0.0.1:58908 127.0.0.1:22
users:(("ssh",pid=1488591,fd=3)) timer:(keepalive,119min,0)
but.. if there is nothing to show, in Bionic we get a segfault:
$ sudo ss -Hnp -o state established 'dport = 22' src 127.0.0.1 dst 127.0.0.1
Segmentation fault
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1913187/+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 1895526] Re: ocfs2 file system no longer write - "disk full" despite lots of free space
Thanks a lot for catching up with this @mfo. And Richard for all the tests. -- 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/1895526 Title: ocfs2 file system no longer write - "disk full" despite lots of free space Status in linux package in Ubuntu: Incomplete Status in ocfs2-tools package in Ubuntu: Confirmed Bug description: Fairly new server on Ubuntu 20.04.1 LTS, 5.4.0-47-generic kernel, DRBD device across 2 sites with one server in each site, ocfs2 filesystem on DRBD device, shared to local network using Samba (and also Samba-AD-DC for network). All packages from "normal" Ubuntu repositories. ocfs2-tools is Installed: 1.8.6-2ubuntu1. The filesystem is around 3.3 TB. Stored data amounted to 24% of this filesystem. Recent updates applied and server restarted Wed 9th Sept after which staff started reporting inability to save to server shares. Checked Samba settings as Windows error messages were at first showing permission issues, but following various checks no wrong Samba settings were found so restarted their server after which the errors were "no space left on disk". Checked on the server terminal and couldn't even "touch" an empty file but got "no space left on disk". Found an article describing limitations caused by ocfs2 cluster size, so copied all data out to a backup machine, recreated the ocfs2 file system using mkfs.ocfs2 -C 64K /dev/drbd0 but again the "no disk space" error keeps happening despite this now being an empty file system. Perhaps it wasn't a cluster size problem in the first instance. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: ocfs2-tools 1.8.6-2ubuntu1 ProcVersionSignature: Ubuntu 5.4.0-47.51-generic 5.4.55 Uname: Linux 5.4.0-47-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.8 Architecture: amd64 CasperMD5CheckResult: pass Date: Mon Sep 14 12:23:35 2020 InstallationDate: Installed on 2020-05-06 (130 days ago) InstallationMedia: Ubuntu-Server 20.04 LTS "Focal Fossa" - Release amd64 (20200423) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: ocfs2-tools UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1895526/+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 1891214] Re: targetcli/LIO needs tcm_vhost and xen-scsiback feature enabled OR option disabled
** Changed in: python-rtslib-fb (Ubuntu) Status: Confirmed => Fix Committed -- 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/1891214 Title: targetcli/LIO needs tcm_vhost and xen-scsiback feature enabled OR option disabled Status in linux package in Ubuntu: Fix Released Status in python-rtslib-fb package in Ubuntu: Fix Committed Status in qemu package in Ubuntu: Fix Released Bug description: targetcli-fb was recently included in MAIN and rely on some features that aren't available currently in Ubuntu: ## TCM VHOST /vhost> create b'modprobe: FATAL: Module tcm_vhost not found in directory /lib/modules/... not enabled in Ubuntu kernels. QEMU virtio-scsi feature: https://wiki.qemu.org/Features/VirtioSCSI/TCM_Overview KERNEL option to be enabled: https://cateee.net/lkddb/web-lkddb/TCM_VHOST.html KERNEL TCM documentation: https://www.kernel.org/doc/html/latest/target/tcmu-design.html LIO (LinuxIO) VHOST feature explained: http://linux-iscsi.org/wiki/VHost ## XEN PVSCSI Same happens for XEN: https://wiki.xenproject.org/wiki/Paravirtualized_SCSI PS: this would I would go for a targetcli fabric module disablement instead of enabling the feature. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1891214/+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 1891214] Re: targetcli/LIO needs tcm_vhost and xen-scsiback feature enabled OR option disabled
With suggested fix: [rafaeldtinoco@guestdevel ubuntu]$ sudo targetcli targetcli shell version 2.1.53 Copyright 2011-2013 by Datera, Inc and others. For help on commands, type 'help'. /> ls / o- / .. [...] o- backstores ... [...] | o- block ... [Storage Objects: 0] | o- fileio .. [Storage Objects: 0] | o- pscsi ... [Storage Objects: 0] | o- ramdisk . [Storage Objects: 0] o- iscsi . [Targets: 0] o- loopback .. [Targets: 0] o- vhost . [Targets: 0] /> cd /xen-pvscsi No such path /xen-pvscsi ** Changed in: qemu (Ubuntu) Status: Incomplete => 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/1891214 Title: targetcli/LIO needs tcm_vhost and xen-scsiback feature enabled OR option disabled Status in linux package in Ubuntu: Fix Released Status in python-rtslib-fb package in Ubuntu: Confirmed Status in qemu package in Ubuntu: Fix Released Bug description: targetcli-fb was recently included in MAIN and rely on some features that aren't available currently in Ubuntu: ## TCM VHOST /vhost> create b'modprobe: FATAL: Module tcm_vhost not found in directory /lib/modules/... not enabled in Ubuntu kernels. QEMU virtio-scsi feature: https://wiki.qemu.org/Features/VirtioSCSI/TCM_Overview KERNEL option to be enabled: https://cateee.net/lkddb/web-lkddb/TCM_VHOST.html KERNEL TCM documentation: https://www.kernel.org/doc/html/latest/target/tcmu-design.html LIO (LinuxIO) VHOST feature explained: http://linux-iscsi.org/wiki/VHost ## XEN PVSCSI Same happens for XEN: https://wiki.xenproject.org/wiki/Paravirtualized_SCSI PS: this would I would go for a targetcli fabric module disablement instead of enabling the feature. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1891214/+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 1891214] Re: targetcli/LIO needs tcm_vhost and xen-scsiback feature enabled OR option disabled
$ sudo modinfo tcm_vhost filename: /lib/modules/5.8.0-18-generic/kernel/drivers/vhost/vhost_scsi.ko license:GPL alias: tcm_vhost description:VHOST_SCSI series fabric driver srcversion: 2AD428CAF926D0F5A58751D depends:target_core_mod,vhost retpoline: Y intree: Y name: vhost_scsi vermagic: 5.8.0-18-generic SMP mod_unload sig_id: PKCS#7 signer: Build time autogenerated kernel key sig_key:36:2A:15:BD:BF:65:C1:25:91:5F:A9:27:E5:4C:76:B8:C2:26:6B:1C sig_hashalgo: sha512 signature: 65:8B:63:37:F0:CE:40:48:AF:56:65:DC:F3:6F:29:DB:E8:D9:A7:86: -- 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/1891214 Title: targetcli/LIO needs tcm_vhost and xen-scsiback feature enabled OR option disabled Status in linux package in Ubuntu: Fix Released Status in python-rtslib-fb package in Ubuntu: Confirmed Status in qemu package in Ubuntu: Incomplete Bug description: targetcli-fb was recently included in MAIN and rely on some features that aren't available currently in Ubuntu: ## TCM VHOST /vhost> create b'modprobe: FATAL: Module tcm_vhost not found in directory /lib/modules/... not enabled in Ubuntu kernels. QEMU virtio-scsi feature: https://wiki.qemu.org/Features/VirtioSCSI/TCM_Overview KERNEL option to be enabled: https://cateee.net/lkddb/web-lkddb/TCM_VHOST.html KERNEL TCM documentation: https://www.kernel.org/doc/html/latest/target/tcmu-design.html LIO (LinuxIO) VHOST feature explained: http://linux-iscsi.org/wiki/VHost ## XEN PVSCSI Same happens for XEN: https://wiki.xenproject.org/wiki/Paravirtualized_SCSI PS: this would I would go for a targetcli fabric module disablement instead of enabling the feature. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1891214/+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 1891214] Re: targetcli/LIO needs tcm_vhost and xen-scsiback feature enabled OR option disabled
/vhost> cd /xen-pvscsi l/xen-pvscsi> ls o- xen-pvscsi .. [Targets: 0] /xen-pvscsi> create b"modprobe: ERROR: could not insert 'xen_scsiback': No such device\n" /xen-pvscsi> quit Will disable the XEN-PVSCSI then. ## XEN PVSCSI Same happens for XEN: https://wiki.xenproject.org/wiki/Paravirtualized_SCSI -- 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/1891214 Title: targetcli/LIO needs tcm_vhost and xen-scsiback feature enabled OR option disabled Status in linux package in Ubuntu: Fix Released Status in python-rtslib-fb package in Ubuntu: Confirmed Status in qemu package in Ubuntu: Incomplete Bug description: targetcli-fb was recently included in MAIN and rely on some features that aren't available currently in Ubuntu: ## TCM VHOST /vhost> create b'modprobe: FATAL: Module tcm_vhost not found in directory /lib/modules/... not enabled in Ubuntu kernels. QEMU virtio-scsi feature: https://wiki.qemu.org/Features/VirtioSCSI/TCM_Overview KERNEL option to be enabled: https://cateee.net/lkddb/web-lkddb/TCM_VHOST.html KERNEL TCM documentation: https://www.kernel.org/doc/html/latest/target/tcmu-design.html LIO (LinuxIO) VHOST feature explained: http://linux-iscsi.org/wiki/VHost ## XEN PVSCSI Same happens for XEN: https://wiki.xenproject.org/wiki/Paravirtualized_SCSI PS: this would I would go for a targetcli fabric module disablement instead of enabling the feature. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1891214/+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 1891214] Re: targetcli/LIO needs tcm_vhost and xen-scsiback feature enabled OR option disabled
Ooops TCM_VHOST is good for Groovy: /> cd /vhost /vhost> create Created target naa.500140533cd76f07. Created TPG 1. /vhost> delete naa.500140533cd76f07 Deleted Target naa.500140533cd76f07. /vhost> quit Tagging linux as Fix Released. ** 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/1891214 Title: targetcli/LIO needs tcm_vhost and xen-scsiback feature enabled OR option disabled Status in linux package in Ubuntu: Fix Released Status in python-rtslib-fb package in Ubuntu: Confirmed Status in qemu package in Ubuntu: Incomplete Bug description: targetcli-fb was recently included in MAIN and rely on some features that aren't available currently in Ubuntu: ## TCM VHOST /vhost> create b'modprobe: FATAL: Module tcm_vhost not found in directory /lib/modules/... not enabled in Ubuntu kernels. QEMU virtio-scsi feature: https://wiki.qemu.org/Features/VirtioSCSI/TCM_Overview KERNEL option to be enabled: https://cateee.net/lkddb/web-lkddb/TCM_VHOST.html KERNEL TCM documentation: https://www.kernel.org/doc/html/latest/target/tcmu-design.html LIO (LinuxIO) VHOST feature explained: http://linux-iscsi.org/wiki/VHost ## XEN PVSCSI Same happens for XEN: https://wiki.xenproject.org/wiki/Paravirtualized_SCSI PS: this would I would go for a targetcli fabric module disablement instead of enabling the feature. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1891214/+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 1891214] Re: targetcli/LIO needs tcm_vhost and xen-scsiback feature enabled OR option disabled
Okay, since TCM_VHOST is experimental in kernel, as we are in feature freeze for Groovy, I'm going to cap the missing features from targetcli so end user does not experience failures from the UI. This bug can serve as a future guidance in enabling those options (specially TCM_VHOST). ** Changed in: qemu (Ubuntu) Milestone: ubuntu-20.10-beta => None ** Changed in: python-rtslib-fb (Ubuntu) Milestone: ubuntu-20.10-beta => None ** Changed in: linux (Ubuntu) Milestone: ubuntu-20.10-beta => None -- 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/1891214 Title: targetcli/LIO needs tcm_vhost and xen-scsiback feature enabled OR option disabled Status in linux package in Ubuntu: Confirmed Status in python-rtslib-fb package in Ubuntu: Confirmed Status in qemu package in Ubuntu: Incomplete Bug description: targetcli-fb was recently included in MAIN and rely on some features that aren't available currently in Ubuntu: ## TCM VHOST /vhost> create b'modprobe: FATAL: Module tcm_vhost not found in directory /lib/modules/... not enabled in Ubuntu kernels. QEMU virtio-scsi feature: https://wiki.qemu.org/Features/VirtioSCSI/TCM_Overview KERNEL option to be enabled: https://cateee.net/lkddb/web-lkddb/TCM_VHOST.html KERNEL TCM documentation: https://www.kernel.org/doc/html/latest/target/tcmu-design.html LIO (LinuxIO) VHOST feature explained: http://linux-iscsi.org/wiki/VHost ## XEN PVSCSI Same happens for XEN: https://wiki.xenproject.org/wiki/Paravirtualized_SCSI PS: this would I would go for a targetcli fabric module disablement instead of enabling the feature. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1891214/+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 1496942] Re: Infiniband (mellanox) SR-IOV and libvirt + libnl problems
Let's keep this bug as Invalid please. There is no issue specific issue to be solved here. Thank you -rafaeldtinoco ** Changed in: linux (Ubuntu) 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/1496942 Title: Infiniband (mellanox) SR-IOV and libvirt + libnl problems Status in linux package in Ubuntu: Invalid Status in linux package in Debian: New Bug description: When trying to start an IB SR-IOV guest by using the following XML: following the Mellanox SR-IOV guide, we are able to start guests using kernel 3.16 (Utopic). We are NOT able to start guests using 3.13 OR 3.19. The following error occurs: 2015-09-17 02:25:07.208+: 52157: info : libvirt version: 1.2.12, package: 1.2.12-0ubuntu14.1~cloud0 2015-09-17 02:25:07.208+: 52157: error : virSecurityDriverLookup:80 : unsupported configuration: Security driver apparmor not enabled 2015-09-17 02:25:42.308+: 52281: info : libvirt version: 1.2.12, package: 1.2.12-0ubuntu14.1~cloud0 2015-09-17 02:25:42.308+: 52281: error : virSecurityDriverLookup:80 : unsupported configuration: Security driver apparmor not enabled 2015-09-17 02:25:48.996+: 52274: error : virNetDevParseVfConfig:1905 : internal error: missing IFLA_VF_INFO in netlink response 2015-09-17 02:25:49.006+: 52274: error : virFileReadAll:1347 : Failed to open file '/var/run/libvirt/hostdevmgr/ib0_vf0': No such file or directory 2015-09-17 02:25:49.006+: 52274: error : virFileReadAll:1347 : Failed to open file '/var/run/libvirt/qemu/ib0_vf0': No such file or directory So probably there is some regression in between 3.16 and 3.19 for the IFLA_VF_INFO feature from netlink AND this has to be backported to kernel 3.13 for Trusty to have IB SR-IOV working. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1496942/+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 1861941] Re: bcache by-uuid links disappear after mounting bcache0
Bionic verification:
$ apt changelog bcache-tools | head -10
bcache-tools (1.0.8-2ubuntu0.18.04.1) bionic; urgency=medium
[ Ryan Harper ]
* Add helper script to read bcache devs superblock (LP: #1861941)
-- Rafael David Tinoco Wed, 05 Aug 2020
17:44:05 -0300
bcache-tools (1.0.8-2build1) artful; urgency=medium
$ dpkg-query -f '${Package}###${Version}\n' -W 'bcache-tools'
bcache-tools###1.0.8-2ubuntu0.18.04.1
$ sudo ./test-bcache.sh
/mnt is a mountpoint
/dev/bcache0: 2 bytes were erased at offset 0x0438 (ext4): 53 ef
writing 1 to /sys/class/block/bcache0/bcache/stop
writing 1 to /sys/fs/bcache/60412675-9103-47b0-9794-91fcfb12d50d/stop
/dev/vdc: 16 bytes were erased at offset 0x1018 (bcache): c6 85 73 f6 4e 1a
45 ca 82 65 f5 7f 48 ba 6d 81
10+0 records in
10+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 0.0173157 s, 606 MB/s
/dev/vdb: 16 bytes were erased at offset 0x1018 (bcache): c6 85 73 f6 4e 1a
45 ca 82 65 f5 7f 48 ba 6d 81
10+0 records in
10+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 0.00634546 s, 1.7 GB/s
UUID: c3758ea3-0e2c-42e3-bb77-da27292d2476
Set UUID: b2b21f55-3599-461a-b162-8377d85fbc34
version:0
nbuckets: 2048
block_size: 1
bucket_size:1024
nr_in_set: 1
nr_this_dev:0
first_bucket: 1
UUID: f4001b7e-386e-4ca3-a5e0-d53f100d156f
Set UUID: b2b21f55-3599-461a-b162-8377d85fbc34
version:1
block_size: 1
data_offset:16
/dev/vdc
tee: /sys/fs/bcache/register: Invalid argument
/dev/vdb
tee: /sys/fs/bcache/register: Invalid argument
total 0
drwxr-xr-x 2 root root 60 Aug 21 14:03 .
drwxr-xr-x 3 root root 60 Aug 21 14:03 ..
lrwxrwxrwx 1 root root 13 Aug 21 14:03 f4001b7e-386e-4ca3-a5e0-d53f100d156f ->
../../bcache0
Creating filesystems on bcache0
mke2fs 1.44.1 (24-Mar-2018)
Discarding device blocks: done
Creating filesystem with 262142 4k blocks and 65536 inodes
Filesystem UUID: 4ade91a9-6176-4a93-a34f-158fa08d0091
Superblock backups stored on blocks:
32768, 98304, 163840, 229376
Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done
mounting bcache0 to /mnt
total 0
drwxr-xr-x 2 root root 60 Aug 21 14:03 .
drwxr-xr-x 3 root root 60 Aug 21 14:03 ..
lrwxrwxrwx 1 root root 13 Aug 21 14:03 f4001b7e-386e-4ca3-a5e0-d53f100d156f ->
../../bcache0
Everything OK
** Tags removed: verification-needed verification-needed-bionic
** Tags added: verification-done verification-done-bionic
--
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/1861941
Title:
bcache by-uuid links disappear after mounting bcache0
Status in bcache-tools package in Ubuntu:
Fix Released
Status in linux package in Ubuntu:
Fix Committed
Status in systemd package in Ubuntu:
Fix Released
Status in bcache-tools source package in Bionic:
Fix Committed
Status in systemd source package in Bionic:
Won't Fix
Status in bcache-tools source package in Focal:
Fix Released
Status in systemd source package in Focal:
In Progress
Bug description:
SRU TEAM: The last 2 commits show a summary for the merges/changes
I added some specific (to Bionic) notes in the template.
Thanks!
[Impact]
* bcache-tools udev created symlinks might disappear when other udev
events are processed for the same devices.
* after mkfs.XXX in /dev/bcacheY you might face a condition where
/dev/bcache/by-{uuid,label}/zzz symlinks are gone.
* /dev/bcache/by-{uuid,label}/ symlinks are important so bcache
devices can be addressed by their UUIDs and not the ordering they were
assembled (MAAS depends on this feature, for example).
* it was also discussed in this bug that systemd-udev should *not*
populate /dev/disk/by-uuid/ with symlinks of disks that were bcache
backing devices. this was turned into a discussion whether blkid
should report those or not, and this discussion "died" after sometime.
This last item is what the systemd update is all about: to disallow
/dev/disk/by-XXX/ creation for bcache backing devices (a simple
change that will reduce end users confusion).
[Test Case]
* The reproducer script is here:
https://paste.ubuntu.com/p/37KGy2Smnp/
* Bionic can't reproduce the issue with the 18.04 kernel, nor with
the HWE kernel. Nevertheless, it is preferable that Bionic also do the
same thing: to read bcache superblock and feed environment for
/dev/bcache/by-{uuid,label} symlinks creation.
[Regression Potential]
* We are not depending on bcache device udev events any more when
creating the /dev/bcache/by-{uuid,label}/ symli
[Kernel-packages] [Bug 1891214] Re: targetcli/LIO needs tcm_vhost and xen-scsiback feature enabled OR option disabled
** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed ** Changed in: python-rtslib-fb (Ubuntu) Status: In Progress => Confirmed ** Changed in: python-rtslib-fb (Ubuntu) Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned) -- 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/1891214 Title: targetcli/LIO needs tcm_vhost and xen-scsiback feature enabled OR option disabled Status in linux package in Ubuntu: Confirmed Status in python-rtslib-fb package in Ubuntu: Confirmed Status in qemu package in Ubuntu: New Bug description: targetcli-fb was recently included in MAIN and rely on some features that aren't available currently in Ubuntu: ## TCM VHOST /vhost> create b'modprobe: FATAL: Module tcm_vhost not found in directory /lib/modules/... not enabled in Ubuntu kernels. QEMU virtio-scsi feature: https://wiki.qemu.org/Features/VirtioSCSI/TCM_Overview KERNEL option to be enabled: https://cateee.net/lkddb/web-lkddb/TCM_VHOST.html KERNEL TCM documentation: https://www.kernel.org/doc/html/latest/target/tcmu-design.html LIO (LinuxIO) VHOST feature explained: http://linux-iscsi.org/wiki/VHost ## XEN PVSCSI Same happens for XEN: https://wiki.xenproject.org/wiki/Paravirtualized_SCSI PS: this would I would go for a targetcli fabric module disablement instead of enabling the feature. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1891214/+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 1891214] Re: targetcli/LIO needs tcm_vhost and xen-scsiback feature enabled OR option disabled
Please other teams/people, let me know your thoughts. I'm able to disable those existing fabric LIO modules, but... at least TCM VHOST might be worth to be kept (if we can explore/enable in QEMU). Cheers ** Summary changed: - targetcli/LIO needs tcm_vhost feature enabled + targetcli/LIO needs tcm_vhost and xen-scsiback feature enabled OR option disabled ** Description changed: + targetcli-fb was recently included in MAIN and rely on some features + that aren't available currently in Ubuntu: - targetcli-fb was recently included in MAIN and one of its features is the VHOST TCM: + ## TCM VHOST - /vhost> create + /vhost> create b'modprobe: FATAL: Module tcm_vhost not found in directory /lib/modules/... not enabled in Ubuntu kernels. QEMU virtio-scsi feature: https://wiki.qemu.org/Features/VirtioSCSI/TCM_Overview KERNEL option to be enabled: https://cateee.net/lkddb/web-lkddb/TCM_VHOST.html KERNEL TCM documentation: https://www.kernel.org/doc/html/latest/target/tcmu-design.html LIO (LinuxIO) VHOST feature explained: http://linux-iscsi.org/wiki/VHost + + ## XEN PVSCSI + + Same happens for XEN: + + https://wiki.xenproject.org/wiki/Paravirtualized_SCSI + + PS: this would I would go for a targetcli fabric module disablement + instead of enabling the feature. ** Changed in: qemu (Ubuntu) Milestone: None => ubuntu-20.10-beta ** Changed in: python-rtslib-fb (Ubuntu) Milestone: None => ubuntu-20.10-beta ** Changed in: linux (Ubuntu) Milestone: None => ubuntu-20.10-beta -- 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/1891214 Title: targetcli/LIO needs tcm_vhost and xen-scsiback feature enabled OR option disabled Status in linux package in Ubuntu: Incomplete Status in python-rtslib-fb package in Ubuntu: In Progress Status in qemu package in Ubuntu: New Bug description: targetcli-fb was recently included in MAIN and rely on some features that aren't available currently in Ubuntu: ## TCM VHOST /vhost> create b'modprobe: FATAL: Module tcm_vhost not found in directory /lib/modules/... not enabled in Ubuntu kernels. QEMU virtio-scsi feature: https://wiki.qemu.org/Features/VirtioSCSI/TCM_Overview KERNEL option to be enabled: https://cateee.net/lkddb/web-lkddb/TCM_VHOST.html KERNEL TCM documentation: https://www.kernel.org/doc/html/latest/target/tcmu-design.html LIO (LinuxIO) VHOST feature explained: http://linux-iscsi.org/wiki/VHost ## XEN PVSCSI Same happens for XEN: https://wiki.xenproject.org/wiki/Paravirtualized_SCSI PS: this would I would go for a targetcli fabric module disablement instead of enabling the feature. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1891214/+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 1891214] Re: targetcli/LIO needs tcm_vhost feature enabled
I have flagged this as affecting: - targetcli-fb (vhost feature broken) - QEMU (vhost scsi support enabled ?) - kernel (would need TCM_VHOST feature enabled) ** Also affects: python-rtslib-fb (Ubuntu) Importance: Undecided Status: New ** No longer affects: targetcli-fb (Ubuntu) ** Changed in: python-rtslib-fb (Ubuntu) Status: New => In Progress ** Changed in: python-rtslib-fb (Ubuntu) Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco) -- 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/1891214 Title: targetcli/LIO needs tcm_vhost feature enabled Status in linux package in Ubuntu: New Status in python-rtslib-fb package in Ubuntu: In Progress Status in qemu package in Ubuntu: New Bug description: targetcli-fb was recently included in MAIN and one of its features is the VHOST TCM: /vhost> create b'modprobe: FATAL: Module tcm_vhost not found in directory /lib/modules/... not enabled in Ubuntu kernels. QEMU virtio-scsi feature: https://wiki.qemu.org/Features/VirtioSCSI/TCM_Overview KERNEL option to be enabled: https://cateee.net/lkddb/web-lkddb/TCM_VHOST.html KERNEL TCM documentation: https://www.kernel.org/doc/html/latest/target/tcmu-design.html LIO (LinuxIO) VHOST feature explained: http://linux-iscsi.org/wiki/VHost To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1891214/+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 1891214] [NEW] targetcli/LIO needs tcm_vhost feature enabled
Public bug reported: targetcli-fb was recently included in MAIN and one of its features is the VHOST TCM: /vhost> create b'modprobe: FATAL: Module tcm_vhost not found in directory /lib/modules/... not enabled in Ubuntu kernels. QEMU virtio-scsi feature: https://wiki.qemu.org/Features/VirtioSCSI/TCM_Overview KERNEL option to be enabled: https://cateee.net/lkddb/web-lkddb/TCM_VHOST.html KERNEL TCM documentation: https://www.kernel.org/doc/html/latest/target/tcmu-design.html LIO (LinuxIO) VHOST feature explained: http://linux-iscsi.org/wiki/VHost ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Affects: python-rtslib-fb (Ubuntu) Importance: Undecided Assignee: Rafael David Tinoco (rafaeldtinoco) Status: In Progress ** Affects: qemu (Ubuntu) Importance: Undecided Status: New ** Also affects: qemu (Ubuntu) Importance: Undecided Status: New ** Also affects: linux (Ubuntu) Importance: Undecided Status: New ** Changed in: targetcli-fb (Ubuntu) Status: New => In Progress ** Changed in: targetcli-fb (Ubuntu) Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco) -- 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/1891214 Title: targetcli/LIO needs tcm_vhost feature enabled Status in linux package in Ubuntu: New Status in python-rtslib-fb package in Ubuntu: In Progress Status in qemu package in Ubuntu: New Bug description: targetcli-fb was recently included in MAIN and one of its features is the VHOST TCM: /vhost> create b'modprobe: FATAL: Module tcm_vhost not found in directory /lib/modules/... not enabled in Ubuntu kernels. QEMU virtio-scsi feature: https://wiki.qemu.org/Features/VirtioSCSI/TCM_Overview KERNEL option to be enabled: https://cateee.net/lkddb/web-lkddb/TCM_VHOST.html KERNEL TCM documentation: https://www.kernel.org/doc/html/latest/target/tcmu-design.html LIO (LinuxIO) VHOST feature explained: http://linux-iscsi.org/wiki/VHost To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1891214/+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 1729145] Re: /dev/bcache/by-uuid links not created after reboot
Anyone interested in this bug, please take a look at: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1861941 Good summary of the issue: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1861941/comments/27 https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1861941/comments/47 https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1861941/comments/56 https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1861941/comments/62 And the fix made at bcache-tools for that bug (kernel patch made to fix this bug will asked to be removed soon, as that fix solves this 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/1729145 Title: /dev/bcache/by-uuid links not created after reboot Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Fix Released Status in linux source package in Zesty: Won't Fix Status in linux source package in Artful: Fix Released Status in linux source package in Bionic: Fix Released Bug description: 1. $ lsb_release -rd Description: Ubuntu 17.10 Release: 17.10 2. $ apt-cache policy linux-image-`uname -r` linux-image-4.13.0-16-generic: Installed: 4.13.0-16.19 Candidate: 4.13.0-16.19 Version table: *** 4.13.0-16.19 500 500 http://nova.clouds.archive.ubuntu.com/ubuntu artful/main amd64 Packages 100 /var/lib/dpkg/status 3. After creating some bcache devices and rebooting /dev/bcache/by-uuid/ -> ../../bcacheN symlinks point to the current bcache device which is caching the dev.uuid found after creating a backing device. 4. /dev/bcache/by-uuid does not exist and there are not symlinks underneath It appears that since the initramfs loads the bcache module which probes and finds all of the cache devices and backing devices then once the rootfs is mounted and udev gets to run, the bcache kernel module does not emit the CACHED_UUID value into the environment if the underlying devices are already registered. In dmesg, one can see that prior to mounting the rootfs, we see bcache register events: [5.333973] bcache: register_bdev() registered backing device vdb2 [5.354138] bcache: register_bdev() registered backing device vdb4 [5.365665] bcache: register_bdev() registered backing device vdb3 [5.397720] bcache: bch_journal_replay() journal replay done, 0 keys in 1 entries, seq 1 [5.428683] bcache: register_cache() registered cache device vdb1 then rootfs ismounted and systemd starts systemd-udev [9.350889] systemd[1]: Listening on udev Kernel Socket. And then the coldplug replay of kernel events triggers /lib/udev/rules.d/69-bcache.rules which invokes /lib/udev/bcache-register which writes the device name (/dev/vdb1 or /dev/bcache0) into /sys/fs/bcache/register and results is the bcache kernel driver attempting to register the block device. However, there is already a bcache device associated already and registration fails [ 11.173141] bcache: register_bcache() error opening /dev/vdb2: device already registered [ 11.184617] bcache: register_bcache() error opening /dev/vdb3: device already registered [ 11.199130] bcache: register_bcache() error opening /dev/vdb1: device already registered [ 11.271694] bcache: register_bcache() error opening /dev/vdb4: device already registered The problem then is that only a kernel call to bch_cached_dev_run() which happens like this: bcache_register() register_bdev() bch_cached_dev_run() kobject_uevent_env(_to_dev(d->disk)->kobj, KOBJ_CHANGE, env); where env includes: "DRIVER=bcache", kasprintf(GFP_KERNEL, "CACHED_UUID=%pU", dc->sb.uuid), NULL, NULL, }; Since that event is not emitted for any previously registered device, then the symlink will not be created. ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: linux-image-4.13.0-16-generic 4.13.0-16.19 ProcVersionSignature: User Name 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Oct 31 22:09 seq crw-rw 1 root audio 116, 33 Oct 31 22:09 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay' ApportVersion: 2.20.7-0ubuntu3.1 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: N/A Date: Wed Nov 1 01:39:01 2017 Ec2AMI: ami-030b Ec2AMIManifest: FIXME Ec2AvailabilityZone: nova Ec2InstanceType: m1.small Ec2Kernel: unavailable Ec2Ramdisk: unavailable IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig' Lsusb: Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd Bus
[Kernel-packages] [Bug 1886364] Re: initiator causes kernel crash when login lun/disk on Focal
Its in kernel team's hands from my POV. Thanks for reporting this! ** Tags removed: server-next -- 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/1886364 Title: initiator causes kernel crash when login lun/disk on Focal Status in ceph-iscsi package in Ubuntu: Invalid Status in linux package in Ubuntu: Confirmed Status in linux source package in Eoan: Triaged Status in linux source package in Focal: Confirmed Bug description: Software version linaro@j13-r120-t32-09:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 20.04 LTS Release:20.04 Codename: focal linaro@j13-r120-t32-09:~$ uname -a Linux j13-r120-t32-09 5.4.0-37-generic #41-Ubuntu SMP Wed Jun 3 17:57:16 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux linaro@j13-r120-t32-09:~$ stack@j13-r120-t32-09:~/devstack-plugin-ceph$ apt search ceph-iscsi Sorting... Done Full Text Search... Done ceph-iscsi/focal,now 3.4-0ubuntu2 all [installed] common logic and CLI tools for creating and managing LIO gateways for Ceph stack@j13-r120-t32-09:~/devstack-plugin-ceph$ apt search tcmu-runner Sorting... Done Full Text Search... Done libtcmu2/focal,now 1.5.2-5build1 arm64 [installed,automatic] Library that handles the userspace side of the LIO TCM-User backstore tcmu-runner/focal,now 1.5.2-5build1 arm64 [installed] Daemon that handles the userspace side of the LIO TCM-User backstore Hardware cavium thx1 root@j13-r120-t32-09:/home/linaro# lshw -c cpu *-cpu description: CPU product: ARM (CN88xx) vendor: CN8890-2000BG2601-CP-Y-G physical id: 2e bus info: cpu@0 version: 2.1 serial: CPU Serial# slot: Socket size: 2GHz capacity: 2GHz clock: 156MHz capabilities: lm configuration: cores=48 enabledcores=48 root@j13-r120-t32-09:/home/linaro# lshw -c system j13-r120-t32-09 description: System product: R120-T32-00 (01234567890123456789AB) vendor: GIGABYTE version: 0100 serial: GHG2N2912A0009 width: 64 bits capabilities: smbios-3.0.0 dmi-3.0.0 smp cp15_barrier setend swp tagged_addr_disabled configuration: chassis=server family=Server sku=01234567890123456789AB uuid=--4000-8000-1C1B0D94A9DE Reproduce Setup ceph iscsi gate way and initiator in the same ubuntu focal all-in-one. iSCSI targets setup 1, $ apt install ceph-iscsi targetcli-fb 2, ceph iscsi config stack@j13-r120-t32-09:~/devstack-plugin-ceph$ sudo cat /etc/ceph/iscsi-gateway.cfg [config] api_port = 5002 api_password = openstack api_user = openstack api_secure = false prometheus_host = 10.101.96.110 gateway_keyring = ceph.client.admin.keyring cluster_name = ceph trusted_ip_list = 10.101.96.110,localhost minimum_gateways = 1 pool = volumes 3, target iqn, client iqn, disk/lun creation https://docs.ceph.com/docs/master//rbd/iscsi-target-cli/ iSCSI initiator setup 1, $ apt install open-iscsi https://www.server-world.info/en/note?os=Ubuntu_18.04=iscsi=3 2, $ iscsiadm -m discovery -t sendtargets -p 10.101.96.110 $ sudo iscsiadm -m node -T iqn.1993-08.org.opendev:01:a9aa4032d2c1 -l Login lun cause crash ceph iscsi gw node [ 122.112611] xfs filesystem being mounted at /var/lib/ceph supports timestamps until 2038 (0x7fff) linaro@j13-r120-t32-09:~$ [ 1512.796815] Unable to handle kernel read from unreadable memory at virtual address 01dc0040 [ 1512.805865] Mem abort info: [ 1512.808647] ESR = 0x9604 [ 1512.811702] EC = 0x25: DABT (current EL), IL = 32 bits [ 1512.817023] SET = 0, FnV = 0 [ 1512.820089] EA = 0, S1PTW = 0 [ 1512.823238] Data abort info: [ 1512.826128] ISV = 0, ISS = 0x0004 [ 1512.829972] CM = 0, WnR = 0 [ 1512.832933] user pgtable: 4k pages, 48-bit VAs, pgdp=000cd14a [ 1512.839410] [01dc0040] pgd= [ 1512.844300] Internal error: Oops: 9604 [#1] SMP [ 1512.849169] Modules linked in: target_core_pscsi target_core_file target_core_iblock iscsi_target_mod xfs xt_REDIRECT xt_comment xt_nat xt_mark xt_connmark ip6table_raw iptable_raw xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp ip6table_mangle ip6table_nat iptable_mangle iptable_nat nf_tables ip6table_filter ip6_tables iptable_filter bpfilter bridge stp llc target_core_user uio target_core_mod nf_conntrack_netlink binfmt_misc nls_iso8859_1 nfnetlink_cttimeout nfnetlink ipmi_ssif ipmi_devintf cavium_rng_vf joydev input_leds ipmi_msghandler cavium_rng thunderx_edac openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c sch_fq_codel ip_tables x_tables autofs4 crct10dif_ce ghash_ce nicvf ast cavium_ptp i2c_algo_bit drm_vram_helper sha2_ce
[Kernel-packages] [Bug 1886364] Re: initiator causes kernel crash when login lun/disk on Focal
** Changed in: ceph-iscsi (Ubuntu) Status: New => Invalid ** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed ** Also affects: linux (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: ceph-iscsi (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: ceph-iscsi (Ubuntu Focal) Importance: Undecided Status: New ** No longer affects: ceph-iscsi (Ubuntu Eoan) ** No longer affects: ceph-iscsi (Ubuntu Focal) ** Changed in: linux (Ubuntu Focal) Status: New => Confirmed ** Changed in: linux (Ubuntu Eoan) Status: New => Triaged ** Tags added: server-next -- 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/1886364 Title: initiator causes kernel crash when login lun/disk on Focal Status in ceph-iscsi package in Ubuntu: Invalid Status in linux package in Ubuntu: Confirmed Status in linux source package in Eoan: Triaged Status in linux source package in Focal: Confirmed Bug description: Software version linaro@j13-r120-t32-09:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 20.04 LTS Release:20.04 Codename: focal linaro@j13-r120-t32-09:~$ uname -a Linux j13-r120-t32-09 5.4.0-37-generic #41-Ubuntu SMP Wed Jun 3 17:57:16 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux linaro@j13-r120-t32-09:~$ stack@j13-r120-t32-09:~/devstack-plugin-ceph$ apt search ceph-iscsi Sorting... Done Full Text Search... Done ceph-iscsi/focal,now 3.4-0ubuntu2 all [installed] common logic and CLI tools for creating and managing LIO gateways for Ceph stack@j13-r120-t32-09:~/devstack-plugin-ceph$ apt search tcmu-runner Sorting... Done Full Text Search... Done libtcmu2/focal,now 1.5.2-5build1 arm64 [installed,automatic] Library that handles the userspace side of the LIO TCM-User backstore tcmu-runner/focal,now 1.5.2-5build1 arm64 [installed] Daemon that handles the userspace side of the LIO TCM-User backstore Hardware cavium thx1 root@j13-r120-t32-09:/home/linaro# lshw -c cpu *-cpu description: CPU product: ARM (CN88xx) vendor: CN8890-2000BG2601-CP-Y-G physical id: 2e bus info: cpu@0 version: 2.1 serial: CPU Serial# slot: Socket size: 2GHz capacity: 2GHz clock: 156MHz capabilities: lm configuration: cores=48 enabledcores=48 root@j13-r120-t32-09:/home/linaro# lshw -c system j13-r120-t32-09 description: System product: R120-T32-00 (01234567890123456789AB) vendor: GIGABYTE version: 0100 serial: GHG2N2912A0009 width: 64 bits capabilities: smbios-3.0.0 dmi-3.0.0 smp cp15_barrier setend swp tagged_addr_disabled configuration: chassis=server family=Server sku=01234567890123456789AB uuid=--4000-8000-1C1B0D94A9DE Reproduce Setup ceph iscsi gate way and initiator in the same ubuntu focal all-in-one. iSCSI targets setup 1, $ apt install ceph-iscsi targetcli-fb 2, ceph iscsi config stack@j13-r120-t32-09:~/devstack-plugin-ceph$ sudo cat /etc/ceph/iscsi-gateway.cfg [config] api_port = 5002 api_password = openstack api_user = openstack api_secure = false prometheus_host = 10.101.96.110 gateway_keyring = ceph.client.admin.keyring cluster_name = ceph trusted_ip_list = 10.101.96.110,localhost minimum_gateways = 1 pool = volumes 3, target iqn, client iqn, disk/lun creation https://docs.ceph.com/docs/master//rbd/iscsi-target-cli/ iSCSI initiator setup 1, $ apt install open-iscsi https://www.server-world.info/en/note?os=Ubuntu_18.04=iscsi=3 2, $ iscsiadm -m discovery -t sendtargets -p 10.101.96.110 $ sudo iscsiadm -m node -T iqn.1993-08.org.opendev:01:a9aa4032d2c1 -l Login lun cause crash ceph iscsi gw node [ 122.112611] xfs filesystem being mounted at /var/lib/ceph supports timestamps until 2038 (0x7fff) linaro@j13-r120-t32-09:~$ [ 1512.796815] Unable to handle kernel read from unreadable memory at virtual address 01dc0040 [ 1512.805865] Mem abort info: [ 1512.808647] ESR = 0x9604 [ 1512.811702] EC = 0x25: DABT (current EL), IL = 32 bits [ 1512.817023] SET = 0, FnV = 0 [ 1512.820089] EA = 0, S1PTW = 0 [ 1512.823238] Data abort info: [ 1512.826128] ISV = 0, ISS = 0x0004 [ 1512.829972] CM = 0, WnR = 0 [ 1512.832933] user pgtable: 4k pages, 48-bit VAs, pgdp=000cd14a [ 1512.839410] [01dc0040] pgd= [ 1512.844300] Internal error: Oops: 9604 [#1] SMP [ 1512.849169] Modules linked in: target_core_pscsi target_core_file target_core_iblock iscsi_target_mod xfs xt_REDIRECT xt_comment xt_nat xt_mark xt_connmark ip6table_raw
[Kernel-packages] [Bug 1872021] Re: commissioning fails due to hung tasks setting up ipmitool
Summary... For Ubuntu Bionic, dpkg triggers for systemd (237-3ubuntu10.39) might have caused systemd to hang: [ 363.776878] wait_for_completion+0xba/0x140 [ 363.776890] __flush_work+0x15b/0x210 [ 363.776901] flush_delayed_work+0x41/0x50 [ 363.776908] fsnotify_wait_marks_destroyed+0x15/0x20 [ 363.776912] fsnotify_destroy_group+0x48/0xd0 [ 363.776917] inotify_release+0x1e/0x50 [ 363.776923] __fput+0xea/0x220 [ 363.776929] fput+0xe/0x10 [ 363.776935] task_work_run+0x9d/0xc0 [ 363.776942] exit_to_usermode_loop+0xc0/0xd0 [ 363.776947] do_syscall_64+0x121/0x130 [ 363.776954] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 and [ 364.050206] wait_for_completion+0xba/0x140 [ 364.050238] __synchronize_srcu.part.13+0x85/0xb0 [ 364.050248] synchronize_srcu+0x66/0xe0 [ 364.050256] fsnotify_mark_destroy_workfn+0x7b/0xe0 [ 364.050262] process_one_work+0x1de/0x420 [ 364.050267] worker_thread+0x228/0x410 [ 364.050272] kthread+0x121/0x140 and [ 364.326985] wait_for_completion+0xba/0x140 [ 364.326988] __synchronize_srcu.part.13+0x85/0xb0 [ 364.326993] synchronize_srcu+0x66/0xe0 [ 364.326995] ? synchronize_srcu+0x66/0xe0 [ 364.326996] fsnotify_connector_destroy_workfn+0x4a/0x80 [ 364.326998] process_one_work+0x1de/0x420 [ 364.326999] worker_thread+0x253/0x410 [ 364.327001] kthread+0x121/0x140 All stack traces seem to come from "fsnotify" subsystem and waiting on delayed work (completion) for fsnotify marks destruction after a inotify_release() was called. Completion did not happen for the past 2 minutes. Without a kernel dump it is hard to tell if completion was still ok - due to kthread being overloaded doing scheduled work and/or the marks group destruction - or there was a dead lock for the completion due to a kernel bug. If this is reproducible, I think that having a kernel dump would help identifying the issue. I'm letting the kernel team to handle this and marking all other issues as dealt per previous comments. ** No longer affects: ipmitool (Ubuntu) ** Changed in: maas Status: New => Invalid ** Summary changed: - commissioning fails due to hung tasks setting up ipmitool + [Ubuntu][Bionic] systemd caused kernel to hang on fsnotify wait-on-completion ** Also affects: linux (Ubuntu) Importance: Undecided Status: New ** No longer affects: linux (Ubuntu) ** Project changed: linux => linux (Ubuntu) ** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Eoan) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Bionic) Status: New => Triaged ** Changed in: linux (Ubuntu Bionic) Importance: Undecided => Medium -- 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/1872021 Title: [Ubuntu][Bionic] systemd caused kernel to hang on fsnotify wait-on- completion Status in MAAS: Invalid Status in linux package in Ubuntu: Incomplete Status in linux source package in Bionic: Triaged Status in linux source package in Eoan: Incomplete Status in linux source package in Focal: Incomplete Bug description: This is with MAAS 2.7.0, commissioning an HP DL385 G7 with Bionic. During the first boot, the machine performs an apt-get upgrade, which includes an update of ipmitool (1.8.18-5ubuntu0.1) and freeipmi-tools (1.4.11-1.1ubuntu4.1). This triggers hung tasks: [ 66.457048] cloud-init[1534]: Setting up ipmitool (1.8.18-5ubuntu0.1) ... Starting IPMI event daemon... [ OK ] Started IPMI event daemon. [ 67.240857] cloud-init[1534]: Setting up freeipmi-tools (1.4.11-1.1ubuntu4.1) ... [ 67.254241] cloud-init[1534]: Processing triggers for systemd (237-3ubuntu10.39) ... [ 242.642684] INFO: task systemd:1 blocked for more than 120 seconds. [ 242.725654] Not tainted 4.15.0-96-generic #97-Ubuntu [ 242.799835] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 242.906319] INFO: task kworker/u49:0:6 blocked for more than 120 seconds. [ 242.997214] Not tainted 4.15.0-96-generic #97-Ubuntu [ 243.072024] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 247.381896] cloud-init[1534]: Failed to reload daemon: Connection timed out [ 247.385109] cloud-init[1534]: Processing triggers for man-db (2.8.3-2ubuntu0.1) ... [ 249.828279] cloud-init[1534]: Processing triggers for ureadahead
[Kernel-packages] [Bug 1866012] Re: depmod ERROR during Setting up linux-modules-5.4.0-17-generic
*** This bug is a duplicate of bug 1864992 *** https://bugs.launchpad.net/bugs/1864992 Im marking this bug as a duplicate of: https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1864992 ** This bug has been marked a duplicate of bug 1864992 depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin' -- 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/1866012 Title: depmod ERROR during Setting up linux-modules-5.4.0-17-generic Status in kmod package in Ubuntu: New Status in linux package in Ubuntu: Invalid Bug description: Steps to reproduce: 1. Deploy Focal on a KVM ndoe, enable proposed 2. Run sudo apt dist-upgrade The console will be flushed with: Setting up libisc1105:amd64 (1:9.11.16+dfsg-3~build1) ... Setting up linux-modules-5.4.0-17-generic (5.4.0-17.21) ... depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-17-generic/modules.builtin.bin' depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-17-generic/modules.builtin.bin' depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-17-generic/modules.builtin.bin' depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-17-generic/modules.builtin.bin' depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-17-generic/modules.builtin.bin' Setting up apt-utils (1.9.12) ... Setting up libselinux1-dev:amd64 (3.0-1build2) ... Setting up libglib2.0-0:amd64 (2.64.0-1) ... ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.4.0-14-generic 5.4.0-14.17 ProcVersionSignature: User Name 5.4.0-14.17-generic 5.4.18 Uname: Linux 5.4.0-14-generic x86_64 AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Mar 4 08:29 seq crw-rw 1 root audio 116, 33 Mar 4 08:29 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu18 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: Date: Wed Mar 4 09:06:42 2020 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' Lsusb: Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Lsusb-t: /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M MachineType: QEMU Standard PC (i440FX + PIIX, 1996) PciMultimedia: ProcFB: 0 cirrusdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-14-generic root=UUID=36e162f3-41b5-4487-a6dc-09ba4e37d3bf ro console=tty1 console=ttyS0 RelatedPackageVersions: linux-restricted-modules-5.4.0-14-generic N/A linux-backports-modules-5.4.0-14-generic N/A linux-firmware1.186 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' SourcePackage: linux-5.4 StagingDrivers: exfat UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: 1.10.2-1ubuntu1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-i440fx-bionic dmi.modalias: dmi:bvnSeaBIOS:bvr1.10.2-1ubuntu1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-bionic:cvnQEMU:ct1:cvrpc-i440fx-bionic: dmi.product.name: Standard PC (i440FX + PIIX, 1996) dmi.product.version: pc-i440fx-bionic dmi.sys.vendor: QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1866012/+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 1866012] Re: depmod ERROR during Setting up linux-modules-5.4.0-17-generic
*** This bug is a duplicate of bug 1864992 *** https://bugs.launchpad.net/bugs/1864992 https://bugs.launchpad.net/curtin/+bug/1864992/comments/34 https://bugs.launchpad.net/curtin/+bug/1864992/comments/35 https://bugs.launchpad.net/curtin/+bug/1864992/comments/36 Issue is in verbosity level of kmod. -- 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/1866012 Title: depmod ERROR during Setting up linux-modules-5.4.0-17-generic Status in kmod package in Ubuntu: New Status in linux package in Ubuntu: Invalid Bug description: Steps to reproduce: 1. Deploy Focal on a KVM ndoe, enable proposed 2. Run sudo apt dist-upgrade The console will be flushed with: Setting up libisc1105:amd64 (1:9.11.16+dfsg-3~build1) ... Setting up linux-modules-5.4.0-17-generic (5.4.0-17.21) ... depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-17-generic/modules.builtin.bin' depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-17-generic/modules.builtin.bin' depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-17-generic/modules.builtin.bin' depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-17-generic/modules.builtin.bin' depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-17-generic/modules.builtin.bin' Setting up apt-utils (1.9.12) ... Setting up libselinux1-dev:amd64 (3.0-1build2) ... Setting up libglib2.0-0:amd64 (2.64.0-1) ... ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.4.0-14-generic 5.4.0-14.17 ProcVersionSignature: User Name 5.4.0-14.17-generic 5.4.18 Uname: Linux 5.4.0-14-generic x86_64 AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Mar 4 08:29 seq crw-rw 1 root audio 116, 33 Mar 4 08:29 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu18 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: Date: Wed Mar 4 09:06:42 2020 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' Lsusb: Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Lsusb-t: /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M MachineType: QEMU Standard PC (i440FX + PIIX, 1996) PciMultimedia: ProcFB: 0 cirrusdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-14-generic root=UUID=36e162f3-41b5-4487-a6dc-09ba4e37d3bf ro console=tty1 console=ttyS0 RelatedPackageVersions: linux-restricted-modules-5.4.0-14-generic N/A linux-backports-modules-5.4.0-14-generic N/A linux-firmware1.186 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' SourcePackage: linux-5.4 StagingDrivers: exfat UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: 1.10.2-1ubuntu1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-i440fx-bionic dmi.modalias: dmi:bvnSeaBIOS:bvr1.10.2-1ubuntu1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-bionic:cvnQEMU:ct1:cvrpc-i440fx-bionic: dmi.product.name: Standard PC (i440FX + PIIX, 1996) dmi.product.version: pc-i440fx-bionic dmi.sys.vendor: QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1866012/+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 1866012] Re: depmod ERROR during Setting up linux-modules-5.4.0-17-generic
Related bugs: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1863261 https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1866012 https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1864992 -- 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/1866012 Title: depmod ERROR during Setting up linux-modules-5.4.0-17-generic Status in kmod package in Ubuntu: New Status in linux package in Ubuntu: Invalid Bug description: Steps to reproduce: 1. Deploy Focal on a KVM ndoe, enable proposed 2. Run sudo apt dist-upgrade The console will be flushed with: Setting up libisc1105:amd64 (1:9.11.16+dfsg-3~build1) ... Setting up linux-modules-5.4.0-17-generic (5.4.0-17.21) ... depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-17-generic/modules.builtin.bin' depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-17-generic/modules.builtin.bin' depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-17-generic/modules.builtin.bin' depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-17-generic/modules.builtin.bin' depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-17-generic/modules.builtin.bin' Setting up apt-utils (1.9.12) ... Setting up libselinux1-dev:amd64 (3.0-1build2) ... Setting up libglib2.0-0:amd64 (2.64.0-1) ... ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.4.0-14-generic 5.4.0-14.17 ProcVersionSignature: User Name 5.4.0-14.17-generic 5.4.18 Uname: Linux 5.4.0-14-generic x86_64 AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Mar 4 08:29 seq crw-rw 1 root audio 116, 33 Mar 4 08:29 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu18 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: Date: Wed Mar 4 09:06:42 2020 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' Lsusb: Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Lsusb-t: /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M MachineType: QEMU Standard PC (i440FX + PIIX, 1996) PciMultimedia: ProcFB: 0 cirrusdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-14-generic root=UUID=36e162f3-41b5-4487-a6dc-09ba4e37d3bf ro console=tty1 console=ttyS0 RelatedPackageVersions: linux-restricted-modules-5.4.0-14-generic N/A linux-backports-modules-5.4.0-14-generic N/A linux-firmware1.186 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' SourcePackage: linux-5.4 StagingDrivers: exfat UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: 1.10.2-1ubuntu1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-i440fx-bionic dmi.modalias: dmi:bvnSeaBIOS:bvr1.10.2-1ubuntu1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-bionic:cvnQEMU:ct1:cvrpc-i440fx-bionic: dmi.product.name: Standard PC (i440FX + PIIX, 1996) dmi.product.version: pc-i440fx-bionic dmi.sys.vendor: QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1866012/+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 1864992] Re: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin'
Alright, sorry for the delay, I'm revisiting this now... -- 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/1864992 Title: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin' Status in curtin: Invalid Status in subiquity: New Status in kmod package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: During a Focal install from the ISO image several errors like: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin' are logged in curtin's install logs. The installed system boots and works fine, but the error is clearly something we want to get rid of. At first glance this seems related to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1863261 but the version of initramfs-tools in both the installer and installed system (checked with `chroot /target dpkg -l initramfs-tools` during the installation) is 0.136ubuntu1, which should contain Rafael's fix for that bug. I wonder if the update-initramfs diversion has a role here. I verified this happens at least on amd64 and arm64. I'm attaching the full install logs for a amd64 installation. --- ProblemType: Bug AlsaVersion: Advanced Linux Sound Architecture Driver Version k5.4.0-14-generic. AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu18 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', '/dev/snd/controlC0', '/dev/snd/hwC0D0', '/dev/snd/pcmC0D0c', '/dev/snd/pcmC0D0p', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: N/A Card0.Amixer.info: Error: [Errno 2] No such file or directory: 'amixer' Card0.Amixer.values: Error: [Errno 2] No such file or directory: 'amixer' CasperVersion: 1.439 DistroRelease: Ubuntu 20.04 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' LiveMediaBuild: Ubuntu-Server 20.04 LTS "Focal Fossa" - Alpha amd64 (20200225) Lsusb: Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU USB Tablet Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Lsusb-t: /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 480M MachineType: QEMU Standard PC (Q35 + ICH9, 2009) NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair Package: linux (not installed) ProcEnviron: TERM=linux PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 ProcFB: 0 qxldrmfb ProcKernelCmdLine: initrd=/casper/initrd quiet --- maybe-ubiquity ProcVersionSignature: Ubuntu 5.4.0-14.17-generic 5.4.18 RelatedPackageVersions: linux-restricted-modules-5.4.0-14-generic N/A linux-backports-modules-5.4.0-14-generic N/A linux-firmware1.186 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' Tags: focal uec-images Uname: Linux 5.4.0-14-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: 1.13.0-1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-q35-4.2 dmi.modalias: dmi:bvnSeaBIOS:bvr1.13.0-1:bd04/01/2014:svnQEMU:pnStandardPC(Q35+ICH9,2009):pvrpc-q35-4.2:cvnQEMU:ct1:cvrpc-q35-4.2: dmi.product.name: Standard PC (Q35 + ICH9, 2009) dmi.product.version: pc-q35-4.2 dmi.sys.vendor: QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/curtin/+bug/1864992/+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 1864992] Re: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin'
At that time .. kmod was 26+20191223-1ubuntu1, now kmod is 27-1ubuntu1... Will check if something happened in that upgrade that made the mkinitramfs change buggy OR its something that was never covered. ** Changed in: kmod (Ubuntu) Importance: Undecided => Medium ** Changed in: linux (Ubuntu) Importance: Undecided => Low ** Changed in: kmod (Ubuntu) Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco) ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco) -- 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/1864992 Title: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin' Status in curtin: Invalid Status in subiquity: New Status in kmod package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: During a Focal install from the ISO image several errors like: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin' are logged in curtin's install logs. The installed system boots and works fine, but the error is clearly something we want to get rid of. At first glance this seems related to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1863261 but the version of initramfs-tools in both the installer and installed system (checked with `chroot /target dpkg -l initramfs-tools` during the installation) is 0.136ubuntu1, which should contain Rafael's fix for that bug. I wonder if the update-initramfs diversion has a role here. I verified this happens at least on amd64 and arm64. I'm attaching the full install logs for a amd64 installation. --- ProblemType: Bug AlsaVersion: Advanced Linux Sound Architecture Driver Version k5.4.0-14-generic. AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu18 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', '/dev/snd/controlC0', '/dev/snd/hwC0D0', '/dev/snd/pcmC0D0c', '/dev/snd/pcmC0D0p', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: N/A Card0.Amixer.info: Error: [Errno 2] No such file or directory: 'amixer' Card0.Amixer.values: Error: [Errno 2] No such file or directory: 'amixer' CasperVersion: 1.439 DistroRelease: Ubuntu 20.04 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' LiveMediaBuild: Ubuntu-Server 20.04 LTS "Focal Fossa" - Alpha amd64 (20200225) Lsusb: Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU USB Tablet Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Lsusb-t: /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 480M MachineType: QEMU Standard PC (Q35 + ICH9, 2009) NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair Package: linux (not installed) ProcEnviron: TERM=linux PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 ProcFB: 0 qxldrmfb ProcKernelCmdLine: initrd=/casper/initrd quiet --- maybe-ubiquity ProcVersionSignature: Ubuntu 5.4.0-14.17-generic 5.4.18 RelatedPackageVersions: linux-restricted-modules-5.4.0-14-generic N/A linux-backports-modules-5.4.0-14-generic N/A linux-firmware1.186 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' Tags: focal uec-images Uname: Linux 5.4.0-14-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: 1.13.0-1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-q35-4.2 dmi.modalias: dmi:bvnSeaBIOS:bvr1.13.0-1:bd04/01/2014:svnQEMU:pnStandardPC(Q35+ICH9,2009):pvrpc-q35-4.2:cvnQEMU:ct1:cvrpc-q35-4.2: dmi.product.name: Standard PC (Q35 + ICH9, 2009) dmi.product.version: pc-q35-4.2 dmi.sys.vendor: QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/curtin/+bug/1864992/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~ker
[Kernel-packages] [Bug 1864992] Re: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin'
@dsmythies, @kaihengfeng you seem to be correct. First time I saw that issue was in a kmod regression test iirc. The fix was supposed to be in: initramfs-tools (0.133ubuntu15) focal; urgency=medium from: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1863261 but I see now that might not cover all cases. I'll revisit this today. -- 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/1864992 Title: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin' Status in curtin: Invalid Status in subiquity: New Status in kmod package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: During a Focal install from the ISO image several errors like: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin' are logged in curtin's install logs. The installed system boots and works fine, but the error is clearly something we want to get rid of. At first glance this seems related to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1863261 but the version of initramfs-tools in both the installer and installed system (checked with `chroot /target dpkg -l initramfs-tools` during the installation) is 0.136ubuntu1, which should contain Rafael's fix for that bug. I wonder if the update-initramfs diversion has a role here. I verified this happens at least on amd64 and arm64. I'm attaching the full install logs for a amd64 installation. --- ProblemType: Bug AlsaVersion: Advanced Linux Sound Architecture Driver Version k5.4.0-14-generic. AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu18 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', '/dev/snd/controlC0', '/dev/snd/hwC0D0', '/dev/snd/pcmC0D0c', '/dev/snd/pcmC0D0p', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: N/A Card0.Amixer.info: Error: [Errno 2] No such file or directory: 'amixer' Card0.Amixer.values: Error: [Errno 2] No such file or directory: 'amixer' CasperVersion: 1.439 DistroRelease: Ubuntu 20.04 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' LiveMediaBuild: Ubuntu-Server 20.04 LTS "Focal Fossa" - Alpha amd64 (20200225) Lsusb: Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU USB Tablet Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Lsusb-t: /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 480M MachineType: QEMU Standard PC (Q35 + ICH9, 2009) NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair Package: linux (not installed) ProcEnviron: TERM=linux PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 ProcFB: 0 qxldrmfb ProcKernelCmdLine: initrd=/casper/initrd quiet --- maybe-ubiquity ProcVersionSignature: Ubuntu 5.4.0-14.17-generic 5.4.18 RelatedPackageVersions: linux-restricted-modules-5.4.0-14-generic N/A linux-backports-modules-5.4.0-14-generic N/A linux-firmware1.186 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' Tags: focal uec-images Uname: Linux 5.4.0-14-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: 1.13.0-1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-q35-4.2 dmi.modalias: dmi:bvnSeaBIOS:bvr1.13.0-1:bd04/01/2014:svnQEMU:pnStandardPC(Q35+ICH9,2009):pvrpc-q35-4.2:cvnQEMU:ct1:cvrpc-q35-4.2: dmi.product.name: Standard PC (Q35 + ICH9, 2009) dmi.product.version: pc-q35-4.2 dmi.sys.vendor: QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/curtin/+bug/1864992/+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 1864992] Re: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin'
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1863261 -- 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/1864992 Title: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin' Status in curtin: Invalid Status in subiquity: New Status in kmod package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: During a Focal install from the ISO image several errors like: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin' are logged in curtin's install logs. The installed system boots and works fine, but the error is clearly something we want to get rid of. At first glance this seems related to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1863261 but the version of initramfs-tools in both the installer and installed system (checked with `chroot /target dpkg -l initramfs-tools` during the installation) is 0.136ubuntu1, which should contain Rafael's fix for that bug. I wonder if the update-initramfs diversion has a role here. I verified this happens at least on amd64 and arm64. I'm attaching the full install logs for a amd64 installation. --- ProblemType: Bug AlsaVersion: Advanced Linux Sound Architecture Driver Version k5.4.0-14-generic. AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu18 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', '/dev/snd/controlC0', '/dev/snd/hwC0D0', '/dev/snd/pcmC0D0c', '/dev/snd/pcmC0D0p', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: N/A Card0.Amixer.info: Error: [Errno 2] No such file or directory: 'amixer' Card0.Amixer.values: Error: [Errno 2] No such file or directory: 'amixer' CasperVersion: 1.439 DistroRelease: Ubuntu 20.04 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' LiveMediaBuild: Ubuntu-Server 20.04 LTS "Focal Fossa" - Alpha amd64 (20200225) Lsusb: Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU USB Tablet Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Lsusb-t: /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 480M MachineType: QEMU Standard PC (Q35 + ICH9, 2009) NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair Package: linux (not installed) ProcEnviron: TERM=linux PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 ProcFB: 0 qxldrmfb ProcKernelCmdLine: initrd=/casper/initrd quiet --- maybe-ubiquity ProcVersionSignature: Ubuntu 5.4.0-14.17-generic 5.4.18 RelatedPackageVersions: linux-restricted-modules-5.4.0-14-generic N/A linux-backports-modules-5.4.0-14-generic N/A linux-firmware1.186 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' Tags: focal uec-images Uname: Linux 5.4.0-14-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: 1.13.0-1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-q35-4.2 dmi.modalias: dmi:bvnSeaBIOS:bvr1.13.0-1:bd04/01/2014:svnQEMU:pnStandardPC(Q35+ICH9,2009):pvrpc-q35-4.2:cvnQEMU:ct1:cvrpc-q35-4.2: dmi.product.name: Standard PC (Q35 + ICH9, 2009) dmi.product.version: pc-q35-4.2 dmi.sys.vendor: QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/curtin/+bug/1864992/+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 1852122] Re: ocfs2-tools is causing kernel panics in Ubuntu Focal (Ubuntu-5.4.0-9.12)
VERIFICATION: (k)rafaeldtinoco@ocfs2:~$ apt-cache policy linux-image-5.4.0-14-generic linux-image-5.4.0-14-generic: Installed: 5.4.0-14.17 Candidate: 5.4.0-14.17 Version table: *** 5.4.0-14.17 500 500 http://br.archive.ubuntu.com/ubuntu focal-proposed/main amd64 Packages 100 /var/lib/dpkg/status (k)rafaeldtinoco@ocfs2:~/scripts$ sudo ./ocfs2_reproducer.sh === dlmfs === ocfs2_dlmfs /dlm ocfs2_dlmfs rw,relatime 0 0 === lsmod === ocfs2_stack_o2cb 16384 0 ocfs2_dlm 192512 1 ocfs2_stack_o2cb ocfs2_nodemanager 196608 7 ocfs2_stack_o2cb,ocfs2_dlm,ocfs2_dlmfs ocfs2_stackglue20480 2 ocfs2_stack_o2cb,ocfs2_dlmfs === o2hbmonitor === 1026 o2hbmonitor === o2cluster === o2cb,ocfs2,local === o2cb_ctl === cluster: name = ocfs2 node_count = 1 status = configured === losetup === 200+0 records in 200+0 records out 209715200 bytes (210 MB, 200 MiB) copied, 0.192249 s, 1.1 GB/s === mkfs === mkfs.ocfs2 1.8.6 Cluster stack: o2cb Cluster name: ocfs2 Stack Flags: 0x0 NOTE: Feature extended slot map may be enabled Label: Features: sparse extended-slotmap backup-super unwritten inline-data strict-journal-super xattr indexed-dirs refcount discontig-bg append-dio Block size: 1024 (10 bits) Cluster size: 4096 (12 bits) Volume size: 209715200 (51200 clusters) (204800 blocks) Cluster groups: 7 (tail covers 5120 clusters, rest cover 7680 clusters) Extent allocator size: 2097152 (1 groups) Journal size: 4194304 Node slots: 2 Creating bitmaps: done Initializing superblock: done Writing system files: done Writing superblock: done Writing backup superblock: 0 block(s) Formatting Journals: done Growing extent allocator: done Formatting slot map: done Formatting quota files: done Writing lost+found: done mkfs.ocfs2 successful === mount === Filesystem 1K-blocks Used Available Use% Mounted on /dev/loop0204800 14904189896 8% /mnt cleanup ** Tags removed: verification-needed-eoan ** Tags added: verification-done verification-done-eoan -- 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/1852122 Title: ocfs2-tools is causing kernel panics in Ubuntu Focal (Ubuntu-5.4.0-9.12) Status in OCFS2 Tools: Fix Released Status in linux package in Ubuntu: Fix Released Status in ocfs2-tools package in Ubuntu: Invalid Status in linux source package in Eoan: Fix Committed Status in ocfs2-tools source package in Eoan: Invalid Status in linux source package in Focal: Fix Released Status in ocfs2-tools source package in Focal: Invalid Bug description: [Impact] * Umounts to OCFS2 filesystems will cause a kernel crash in any kernel containing commit e581595ea29c (v5.3-rc1) and not containing its fix b73eba2a867e (v5.5-rc5). [Test Case] * ocfs2_reproducer.sh (attached to this bug) [Regression Potential] * it could cause ocfs2 issues, so I guess its a low impact considering amount of users. * Its a straightforward fix identified by upstream developer and a clean cherry-pick for us. [Other Info] * Original description: I noticed the tests for ocfs2-tools/1.8.6-1ubuntu1 were constantly retrying themselves. It's a feature we have so that transient / occasional failures are auto-retried, but it's misfiring here because we're not detecting that it's a consistent failure. That particular bug is fixed, but it means that ocfs2-tools is failing on ppc64el. Here's the important part of the log, full output attached. [ 85.605738] BUG: Unable to handle kernel data access at 0x01744098 [ 85.605850] Faulting instruction address: 0xc0e81168 [ 85.605901] Oops: Kernel access of bad area, sig: 11 [#1] [ 85.605970] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries [ 85.606029] Modules linked in: ocfs2 quota_tree ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue iptable_mangle xt_TCPMSS xt_tcpudp bpfilter dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua vmx_crypto crct10dif_vpmsum sch_fq_codel ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq libcrc32c crc32c_vpmsum virtio_net virtio_blk net_failover failover [ 85.606291] CPU: 0 PID: 1 Comm: systemd Not tainted 5.3.0-18-generic #19-Ubuntu
[Kernel-packages] [Bug 1852122] Re: ocfs2-tools is causing kernel panics in Ubuntu Focal (Ubuntu-5.4.0-9.12)
Eoan patch was acked. Focal patch is already in latest kernel version. ** Changed in: linux (Ubuntu Focal) Status: In Progress => 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/1852122 Title: ocfs2-tools is causing kernel panics in Ubuntu Focal (Ubuntu-5.4.0-9.12) Status in OCFS2 Tools: Fix Released Status in linux package in Ubuntu: Fix Released Status in ocfs2-tools package in Ubuntu: Invalid Status in linux source package in Eoan: In Progress Status in ocfs2-tools source package in Eoan: Invalid Status in linux source package in Focal: Fix Released Status in ocfs2-tools source package in Focal: Invalid Bug description: [Impact] * Umounts to OCFS2 filesystems will cause a kernel crash in any kernel containing commit e581595ea29c (v5.3-rc1) and not containing its fix b73eba2a867e (v5.5-rc5). [Test Case] * ocfs2_reproducer.sh (attached to this bug) [Regression Potential] * it could cause ocfs2 issues, so I guess its a low impact considering amount of users. * Its a straightforward fix identified by upstream developer and a clean cherry-pick for us. [Other Info] * Original description: I noticed the tests for ocfs2-tools/1.8.6-1ubuntu1 were constantly retrying themselves. It's a feature we have so that transient / occasional failures are auto-retried, but it's misfiring here because we're not detecting that it's a consistent failure. That particular bug is fixed, but it means that ocfs2-tools is failing on ppc64el. Here's the important part of the log, full output attached. [ 85.605738] BUG: Unable to handle kernel data access at 0x01744098 [ 85.605850] Faulting instruction address: 0xc0e81168 [ 85.605901] Oops: Kernel access of bad area, sig: 11 [#1] [ 85.605970] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries [ 85.606029] Modules linked in: ocfs2 quota_tree ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue iptable_mangle xt_TCPMSS xt_tcpudp bpfilter dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua vmx_crypto crct10dif_vpmsum sch_fq_codel ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq libcrc32c crc32c_vpmsum virtio_net virtio_blk net_failover failover [ 85.606291] CPU: 0 PID: 1 Comm: systemd Not tainted 5.3.0-18-generic #19-Ubuntu [ 85.606350] NIP: c0e81168 LR: c054f240 CTR: [ 85.606410] REGS: c0005a3e3700 TRAP: 0300 Not tainted (5.3.0-18-generic) [ 85.606469] MSR: 80009033 CR: 28024448 XER: [ 85.606531] CFAR: 701f9806f638 DAR: 01744098 DSISR: 4000 IRQMASK: 0 [ 85.606531] GPR00: 7374 c0005a3e3990 c19c9100 c0004fe462a8 [ 85.606531] GPR04: c0005856d840 000e 74656772 c0004fe4a568 [ 85.606531] GPR08: c00058568004 01744090 [ 85.606531] GPR12: e8086002 c1d6 7fffddd522d0 [ 85.606531] GPR16: c755e07c [ 85.606531] GPR20:
[Kernel-packages] [Bug 1852122] Re: ocfs2-tools is causing kernel panics in Ubuntu Focal (Ubuntu-5.4.0-9.12)
Patches for Focal and SRU were sent to kernel-t...@lists.ubuntu.com: https://lists.ubuntu.com/archives/kernel-team/2020-January/106845.html https://lists.ubuntu.com/archives/kernel-team/2020-January/106846.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/1852122 Title: ocfs2-tools is causing kernel panics in Ubuntu Focal (Ubuntu-5.4.0-9.12) Status in OCFS2 Tools: Fix Released Status in linux package in Ubuntu: In Progress Status in ocfs2-tools package in Ubuntu: Invalid Status in linux source package in Eoan: In Progress Status in ocfs2-tools source package in Eoan: Invalid Status in linux source package in Focal: In Progress Status in ocfs2-tools source package in Focal: Invalid Bug description: [Impact] * Umounts to OCFS2 filesystems will cause a kernel crash in any kernel containing commit e581595ea29c (v5.3-rc1) and not containing its fix b73eba2a867e (v5.5-rc5). [Test Case] * ocfs2_reproducer.sh (attached to this bug) [Regression Potential] * it could cause ocfs2 issues, so I guess its a low impact considering amount of users. * Its a straightforward fix identified by upstream developer and a clean cherry-pick for us. [Other Info] * Original description: I noticed the tests for ocfs2-tools/1.8.6-1ubuntu1 were constantly retrying themselves. It's a feature we have so that transient / occasional failures are auto-retried, but it's misfiring here because we're not detecting that it's a consistent failure. That particular bug is fixed, but it means that ocfs2-tools is failing on ppc64el. Here's the important part of the log, full output attached. [ 85.605738] BUG: Unable to handle kernel data access at 0x01744098 [ 85.605850] Faulting instruction address: 0xc0e81168 [ 85.605901] Oops: Kernel access of bad area, sig: 11 [#1] [ 85.605970] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries [ 85.606029] Modules linked in: ocfs2 quota_tree ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue iptable_mangle xt_TCPMSS xt_tcpudp bpfilter dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua vmx_crypto crct10dif_vpmsum sch_fq_codel ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq libcrc32c crc32c_vpmsum virtio_net virtio_blk net_failover failover [ 85.606291] CPU: 0 PID: 1 Comm: systemd Not tainted 5.3.0-18-generic #19-Ubuntu [ 85.606350] NIP: c0e81168 LR: c054f240 CTR: [ 85.606410] REGS: c0005a3e3700 TRAP: 0300 Not tainted (5.3.0-18-generic) [ 85.606469] MSR: 80009033 CR: 28024448 XER: [ 85.606531] CFAR: 701f9806f638 DAR: 01744098 DSISR: 4000 IRQMASK: 0 [ 85.606531] GPR00: 7374 c0005a3e3990 c19c9100 c0004fe462a8 [ 85.606531] GPR04: c0005856d840 000e 74656772 c0004fe4a568 [ 85.606531] GPR08: c00058568004 01744090 [ 85.606531] GPR12: e8086002 c1d6 7fffddd522d0 [ 85.606531] GPR16: c755e07c
[Kernel-packages] [Bug 1852122] Re: ocfs2-tools is causing kernel panics in Ubuntu Focal (Ubuntu-5.4.0-9.12)
** Description changed: + + [Impact] + + * Umounts to OCFS2 filesystems will cause a kernel crash in any kernel + containing commit e581595ea29c (v5.3-rc1) and not containing its fix + b73eba2a867e (v5.5-rc5). + + [Test Case] + + * ocfs2_reproducer.sh (attached to this bug) + + [Regression Potential] + + * it could cause ocfs2 issues, so I guess its a low impact considering amount of users. + * Its a straightforward fix identified by upstream developer and a clean cherry-pick for us. + + [Other Info] + + * Original description: + I noticed the tests for ocfs2-tools/1.8.6-1ubuntu1 were constantly retrying themselves. It's a feature we have so that transient / occasional failures are auto-retried, but it's misfiring here because we're not detecting that it's a consistent failure. That particular bug is fixed, but it means that ocfs2-tools is failing on ppc64el. Here's the important part of the log, full output attached. [ 85.605738] BUG: Unable to handle kernel data access at 0x01744098 - [ 85.605850] Faulting instruction address: 0xc0e81168 - [ 85.605901] Oops: Kernel access of bad area, sig: 11 [#1] - [ 85.605970] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries - [ 85.606029] Modules linked in: ocfs2 quota_tree ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue iptable_mangle xt_TCPMSS xt_tcpudp bpfilter dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua vmx_crypto crct10dif_vpmsum sch_fq_codel ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq libcrc32c crc32c_vpmsum virtio_net virtio_blk net_failover failover - [ 85.606291] CPU: 0 PID: 1 Comm: systemd Not tainted 5.3.0-18-generic #19-Ubuntu - [ 85.606350] NIP: c0e81168 LR: c054f240 CTR: - [ 85.606410] REGS: c0005a3e3700 TRAP: 0300 Not tainted (5.3.0-18-generic) - [ 85.606469] MSR: 80009033 CR: 28024448 XER: - [ 85.606531] CFAR: 701f9806f638 DAR: 01744098 DSISR: 4000 IRQMASK: 0 - [ 85.606531] GPR00: 7374 c0005a3e3990 c19c9100 c0004fe462a8 - [ 85.606531] GPR04: c0005856d840 000e 74656772 c0004fe4a568 - [ 85.606531] GPR08: c00058568004 01744090 - [ 85.606531] GPR12: e8086002 c1d6 7fffddd522d0 - [ 85.606531] GPR16: c755e07c - [ 85.606531] GPR20: c000598caca8 c0005a3e3a58 c00058292f00 - [ 85.606531] GPR24: c0eea710 c0005856d840 c755e074 - [ 85.606531] GPR28: 6518907d c0005a3e3a68 c0004fe4b160 027c47b6 - [ 85.607079] NIP [c0e81168] rb_insert_color+0x18/0x1c0 -
[Kernel-packages] [Bug 1852122] Re: ocfs2-tools is causing kernel panics in Ubuntu Focal (Ubuntu-5.4.0-9.12)
Yep, fixes the issue: [ 25.249831] ocfs2: Registered cluster interface o2cb [ 25.257661] OCFS2 User DLM kernel interface loaded [ 25.265196] o2hb: Heartbeat mode set to local [ 34.231435] o2dlm: Joining domain F67405C564CB4A7CAEBA6F6ACCA2C82F [ 34.231436] ( [ 34.231437] 0 [ 34.231438] ) 1 nodes [ 34.231825] JBD2: Ignoring recovery information on journal [ 34.233058] ocfs2: Mounting device (7,0) on (node 0, slot 0) with ordered data mode. [ 38.246001] o2dlm: Leaving domain F67405C564CB4A7CAEBA6F6ACCA2C82F [ 38.247583] ocfs2: Unmounting device (7,0) on (node 0) [ 50.998435] ocfs2: Unregistered cluster interface o2cb [ 51.117395] ocfs2: Registered cluster interface o2cb [ 51.124916] OCFS2 User DLM kernel interface loaded [ 51.131192] o2hb: Heartbeat mode set to local [ 59.999672] o2dlm: Joining domain 1D1FFAA94E654FE6B94AA0E44029CE9E [ 59.999674] ( [ 59.999675] 0 [ 59.999676] ) 1 nodes [ 60.000252] JBD2: Ignoring recovery information on journal [ 60.001543] ocfs2: Mounting device (7,0) on (node 0, slot 0) with ordered data mode. [ 64.043638] o2dlm: Leaving domain 1D1FFAA94E654FE6B94AA0E44029CE9E [ 64.045484] ocfs2: Unmounting device (7,0) on (node 0) [ 70.866574] random: crng init done [ 70.866586] random: 7 urandom warning(s) missed due to ratelimiting I'll propose patch to kernel team. -- 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/1852122 Title: ocfs2-tools is causing kernel panics in Ubuntu Focal (Ubuntu-5.4.0-9.12) Status in OCFS2 Tools: Fix Released Status in linux package in Ubuntu: In Progress Status in ocfs2-tools package in Ubuntu: Invalid Status in linux source package in Eoan: In Progress Status in ocfs2-tools source package in Eoan: Invalid Status in linux source package in Focal: In Progress Status in ocfs2-tools source package in Focal: Invalid Bug description: I noticed the tests for ocfs2-tools/1.8.6-1ubuntu1 were constantly retrying themselves. It's a feature we have so that transient / occasional failures are auto-retried, but it's misfiring here because we're not detecting that it's a consistent failure. That particular bug is fixed, but it means that ocfs2-tools is failing on ppc64el. Here's the important part of the log, full output attached. [ 85.605738] BUG: Unable to handle kernel data access at 0x01744098 [ 85.605850] Faulting instruction address: 0xc0e81168 [ 85.605901] Oops: Kernel access of bad area, sig: 11 [#1] [ 85.605970] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries [ 85.606029] Modules linked in: ocfs2 quota_tree ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue iptable_mangle xt_TCPMSS xt_tcpudp bpfilter dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua vmx_crypto crct10dif_vpmsum sch_fq_codel ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq libcrc32c crc32c_vpmsum virtio_net virtio_blk net_failover failover [ 85.606291] CPU: 0 PID: 1 Comm: systemd Not tainted 5.3.0-18-generic #19-Ubuntu [ 85.606350] NIP: c0e81168 LR: c054f240 CTR: [ 85.606410] REGS: c0005a3e3700 TRAP: 0300 Not tainted (5.3.0-18-generic) [ 85.606469] MSR: 80009033 CR: 28024448 XER: [ 85.606531] CFAR: 701f9806f638 DAR: 01744098 DSISR: 4000 IRQMASK: 0 [ 85.606531] GPR00: 7374 c0005a3e3990 c19c9100 c0004fe462a8 [ 85.606531] GPR04: c0005856d840 000e 74656772 c0004fe4a568
[Kernel-packages] [Bug 1852122] Re: ocfs2-tools is causing kernel panics in Ubuntu Focal (Ubuntu-5.4.0-9.12)
The upstream fix is likely this:
>From b73eba2a867e10b9b4477738677341f3307c07bb Mon Sep 17 00:00:00 2001
From: Gang He
Date: Sat, 4 Jan 2020 13:00:22 -0800
Subject: [PATCH] ocfs2: fix the crash due to call ocfs2_get_dlm_debug once
less
Because ocfs2_get_dlm_debug() function is called once less here, ocfs2
file system will trigger the system crash, usually after ocfs2 file
system is unmounted.
This system crash is caused by a generic memory corruption, these crash
backtraces are not always the same, for exapmle,
ocfs2: Unmounting device (253,16) on (node 172167785)
general protection fault: [#1] SMP PTI
CPU: 3 PID: 14107 Comm: fence_legacy Kdump:
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:__kmalloc+0xa5/0x2a0
Code: 00 00 4d 8b 07 65 4d 8b
RSP: 0018:aa1fc094bbe8 EFLAGS: 00010286
RAX: RBX: d310a8800d7a3faf RCX:
RDX: RSI: 0dc0 RDI: 96e68fc036c0
RBP: d310a8800d7a3faf R08: 96e6ffdb10a0 R09: 752e7079
R10: 0001c513 R11: 04091041 R12: 0dc0
R13: 0039 R14: 96e68fc036c0 R15: 96e68fc036c0
FS: 7f699dfba540() GS:96e6ffd8() knlGS:0
CS: 0010 DS: ES: CR0: 80050033
CR2: 55f3a9d9b768 CR3: 2cd1c000 CR4: 06e0
Call Trace:
ext4_htree_store_dirent+0x35/0x100 [ext4]
htree_dirblock_to_tree+0xea/0x290 [ext4]
ext4_htree_fill_tree+0x1c1/0x2d0 [ext4]
ext4_readdir+0x67c/0x9d0 [ext4]
iterate_dir+0x8d/0x1a0
__x64_sys_getdents+0xab/0x130
do_syscall_64+0x60/0x1f0
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7f699d33a9fb
This regression problem was introduced by commit e581595ea29c ("ocfs: no
need to check return value of debugfs_create functions").
Link: http://lkml.kernel.org/r/20191225061501.13587-1-...@suse.com
Fixes: e581595ea29c ("ocfs: no need to check return value of debugfs_create
functions")
Signed-off-by: Gang He
Acked-by: Joseph Qi
Cc: Mark Fasheh
Cc: Joel Becker
Cc: Junxiao Bi
Cc: Changwei Ge
Cc: Gang He
Cc: Jun Piao
Cc: [5.3+]
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
as reported in upstream bug. Giving it a try to finally suggest as a SRU
to the kernel team.
** Changed in: ocfs2-tools (Ubuntu Eoan)
Status: In Progress => Invalid
** Changed in: ocfs2-tools (Ubuntu Focal)
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/1852122
Title:
ocfs2-tools is causing kernel panics in Ubuntu Focal
(Ubuntu-5.4.0-9.12)
Status in OCFS2 Tools:
Fix Released
Status in linux package in Ubuntu:
In Progress
Status in ocfs2-tools package in Ubuntu:
Invalid
Status in linux source package in Eoan:
In Progress
Status in ocfs2-tools source package in Eoan:
Invalid
Status in linux source package in Focal:
In Progress
Status in ocfs2-tools source package in Focal:
Invalid
Bug description:
I noticed the tests for ocfs2-tools/1.8.6-1ubuntu1 were constantly
retrying themselves. It's a feature we have so that transient /
occasional failures are auto-retried, but it's misfiring here because
we're not detecting that it's a consistent failure. That particular
bug is fixed, but it means that ocfs2-tools is failing on ppc64el.
Here's the important part of the log, full output attached.
[ 85.605738] BUG: Unable to handle kernel data access at 0x01744098
[ 85.605850] Faulting instruction address:
0xc0e81168
[ 85.605901] Oops: Kernel access of bad
area, sig: 11 [#1]
[ 85.605970] LE PAGE_SIZE=64K MMU=Hash SMP
NR_CPUS=2048 NUMA pSeries
[ 85.606029] Modules linked in: ocfs2
quota_tree ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager
ocfs2_stackglue iptable_mangle xt_TCPMSS xt_tcpudp bpfilter dm_multipath
scsi_dh_rdac scsi_dh_emc scsi_dh_alua vmx_crypto crct10dif_vpmsum sch_fq_codel
ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq libcrc32c
crc32c_vpmsum virtio_net virtio_blk net_failover failover
[ 85.606291] CPU: 0 PID: 1 Comm: systemd
Not tainted 5.3.0-18-generic #19-Ubuntu
[
[Kernel-packages] [Bug 1852122] Re: ocfs2-tools is causing kernel panics in Ubuntu Focal (Ubuntu-5.4.0-9.12)
Thanks for checking this Andreas! Looks like upstream got a fix for the issue and Debian has confirmed it worked. With that, I'll check if it fixes the issue indeed and suggest the SRU to the kernel-team so we can unblock ocfs2-tools. -- 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/1852122 Title: ocfs2-tools is causing kernel panics in Ubuntu Focal (Ubuntu-5.4.0-9.12) Status in OCFS2 Tools: Fix Released Status in linux package in Ubuntu: In Progress Status in ocfs2-tools package in Ubuntu: In Progress Status in linux source package in Eoan: In Progress Status in ocfs2-tools source package in Eoan: In Progress Status in linux source package in Focal: In Progress Status in ocfs2-tools source package in Focal: In Progress Bug description: I noticed the tests for ocfs2-tools/1.8.6-1ubuntu1 were constantly retrying themselves. It's a feature we have so that transient / occasional failures are auto-retried, but it's misfiring here because we're not detecting that it's a consistent failure. That particular bug is fixed, but it means that ocfs2-tools is failing on ppc64el. Here's the important part of the log, full output attached. [ 85.605738] BUG: Unable to handle kernel data access at 0x01744098 [ 85.605850] Faulting instruction address: 0xc0e81168 [ 85.605901] Oops: Kernel access of bad area, sig: 11 [#1] [ 85.605970] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries [ 85.606029] Modules linked in: ocfs2 quota_tree ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue iptable_mangle xt_TCPMSS xt_tcpudp bpfilter dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua vmx_crypto crct10dif_vpmsum sch_fq_codel ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq libcrc32c crc32c_vpmsum virtio_net virtio_blk net_failover failover [ 85.606291] CPU: 0 PID: 1 Comm: systemd Not tainted 5.3.0-18-generic #19-Ubuntu [ 85.606350] NIP: c0e81168 LR: c054f240 CTR: [ 85.606410] REGS: c0005a3e3700 TRAP: 0300 Not tainted (5.3.0-18-generic) [ 85.606469] MSR: 80009033 CR: 28024448 XER: [ 85.606531] CFAR: 701f9806f638 DAR: 01744098 DSISR: 4000 IRQMASK: 0 [ 85.606531] GPR00: 7374 c0005a3e3990 c19c9100 c0004fe462a8 [ 85.606531] GPR04: c0005856d840 000e 74656772 c0004fe4a568 [ 85.606531] GPR08: c00058568004 01744090 [ 85.606531] GPR12: e8086002 c1d6 7fffddd522d0 [ 85.606531] GPR16: c755e07c [ 85.606531] GPR20: c000598caca8 c0005a3e3a58 c00058292f00 [ 85.606531] GPR24: c0eea710 c0005856d840 c755e074 [ 85.606531] GPR28:
[Kernel-packages] [Bug 1852122] Re: ocfs2-tools is causing kernel panics in Ubuntu Focal (Ubuntu-5.4.0-9.12)
Last good test: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan/eoan/amd64/o/ocfs2-tools/20190910_143817_4312f@/log.gz Kernel: 5.2.0-15-generic First failure: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan/eoan/amd64/o/ocfs2-tools/20190918_060126_bd321@/log.gz Kernel: 5.3.0-10-generic -- 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/1852122 Title: ocfs2-tools is causing kernel panics in Ubuntu Focal (Ubuntu-5.4.0-9.12) Status in OCFS2 Tools: New Status in linux package in Ubuntu: In Progress Status in ocfs2-tools package in Ubuntu: In Progress Status in linux source package in Eoan: In Progress Status in ocfs2-tools source package in Eoan: In Progress Status in linux source package in Focal: In Progress Status in ocfs2-tools source package in Focal: In Progress Bug description: I noticed the tests for ocfs2-tools/1.8.6-1ubuntu1 were constantly retrying themselves. It's a feature we have so that transient / occasional failures are auto-retried, but it's misfiring here because we're not detecting that it's a consistent failure. That particular bug is fixed, but it means that ocfs2-tools is failing on ppc64el. Here's the important part of the log, full output attached. [ 85.605738] BUG: Unable to handle kernel data access at 0x01744098 [ 85.605850] Faulting instruction address: 0xc0e81168 [ 85.605901] Oops: Kernel access of bad area, sig: 11 [#1] [ 85.605970] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries [ 85.606029] Modules linked in: ocfs2 quota_tree ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue iptable_mangle xt_TCPMSS xt_tcpudp bpfilter dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua vmx_crypto crct10dif_vpmsum sch_fq_codel ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq libcrc32c crc32c_vpmsum virtio_net virtio_blk net_failover failover [ 85.606291] CPU: 0 PID: 1 Comm: systemd Not tainted 5.3.0-18-generic #19-Ubuntu [ 85.606350] NIP: c0e81168 LR: c054f240 CTR: [ 85.606410] REGS: c0005a3e3700 TRAP: 0300 Not tainted (5.3.0-18-generic) [ 85.606469] MSR: 80009033 CR: 28024448 XER: [ 85.606531] CFAR: 701f9806f638 DAR: 01744098 DSISR: 4000 IRQMASK: 0 [ 85.606531] GPR00: 7374 c0005a3e3990 c19c9100 c0004fe462a8 [ 85.606531] GPR04: c0005856d840 000e 74656772 c0004fe4a568 [ 85.606531] GPR08: c00058568004 01744090 [ 85.606531] GPR12: e8086002 c1d6 7fffddd522d0 [ 85.606531] GPR16: c755e07c [ 85.606531] GPR20: c000598caca8 c0005a3e3a58 c00058292f00 [ 85.606531] GPR24: c0eea710
[Kernel-packages] [Bug 1852122] Re: ocfs2-tools autopkgtest is causing kernel panics on service shutdown
I have tested latest focal kernel and looks like the kernel issue is still there. There is an on going thread upstream about that (most likely) and I have explained how to reproduce the issue here: https://github.com/markfasheh/ocfs2-tools/issues/45#issuecomment-572875062 Issue is happening in all arches currently in autopkgtest infrastructure. ** Summary changed: - ocfs2-tools autopkgtest is causing kernel panics on service shutdown + ocfs2-tools is causing kernel panics in Ubuntu Focal (Ubuntu-5.4.0-9.12) ** Also affects: linux (Ubuntu) Importance: Undecided Status: New ** Changed in: linux (Ubuntu) Status: New => In Progress ** Changed in: linux (Ubuntu) Importance: Undecided => Medium ** Also affects: ocfs2-tools (Ubuntu Focal) Importance: Medium Assignee: Rafael David Tinoco (rafaeldtinoco) Status: In Progress ** Also affects: linux (Ubuntu Focal) Importance: Medium Status: In Progress ** Also affects: ocfs2-tools (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Eoan) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Eoan) Status: New => In Progress ** Changed in: ocfs2-tools (Ubuntu Eoan) Status: New => In Progress ** Changed in: ocfs2-tools (Ubuntu Eoan) Importance: Undecided => Medium ** Changed in: linux (Ubuntu Eoan) Importance: Undecided => Medium ** Changed in: ocfs2-tools (Ubuntu Eoan) Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco) -- 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/1852122 Title: ocfs2-tools is causing kernel panics in Ubuntu Focal (Ubuntu-5.4.0-9.12) Status in OCFS2 Tools: New Status in linux package in Ubuntu: In Progress Status in ocfs2-tools package in Ubuntu: In Progress Status in linux source package in Eoan: In Progress Status in ocfs2-tools source package in Eoan: In Progress Status in linux source package in Focal: In Progress Status in ocfs2-tools source package in Focal: In Progress Bug description: I noticed the tests for ocfs2-tools/1.8.6-1ubuntu1 were constantly retrying themselves. It's a feature we have so that transient / occasional failures are auto-retried, but it's misfiring here because we're not detecting that it's a consistent failure. That particular bug is fixed, but it means that ocfs2-tools is failing on ppc64el. Here's the important part of the log, full output attached. [ 85.605738] BUG: Unable to handle kernel data access at 0x01744098 [ 85.605850] Faulting instruction address: 0xc0e81168 [ 85.605901] Oops: Kernel access of bad area, sig: 11 [#1] [ 85.605970] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries [ 85.606029] Modules linked in: ocfs2 quota_tree ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue iptable_mangle xt_TCPMSS xt_tcpudp bpfilter dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua vmx_crypto crct10dif_vpmsum sch_fq_codel ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq libcrc32c crc32c_vpmsum virtio_net virtio_blk net_failover failover [ 85.606291] CPU: 0 PID: 1 Comm: systemd Not tainted 5.3.0-18-generic #19-Ubuntu [ 85.606350] NIP: c0e81168 LR: c054f240 CTR: [ 85.606410] REGS: c0005a3e3700 TRAP: 0300 Not tainted (5.3.0-18-generic) [ 85.606469] MSR: 80009033 CR: 28024448 XER: [ 85.606531] CFAR: 701f9806f638 DAR: 01744098 DSISR: 4000 IRQMASK: 0 [ 85.606531] GPR00: 7374 c0005a3e3990 c19c
[Kernel-packages] [Bug 1852122] Re: ocfs2-tools is causing kernel panics in Ubuntu Focal (Ubuntu-5.4.0-9.12)
Waiting on upstream 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/1852122 Title: ocfs2-tools is causing kernel panics in Ubuntu Focal (Ubuntu-5.4.0-9.12) Status in OCFS2 Tools: New Status in linux package in Ubuntu: In Progress Status in ocfs2-tools package in Ubuntu: In Progress Status in linux source package in Eoan: In Progress Status in ocfs2-tools source package in Eoan: In Progress Status in linux source package in Focal: In Progress Status in ocfs2-tools source package in Focal: In Progress Bug description: I noticed the tests for ocfs2-tools/1.8.6-1ubuntu1 were constantly retrying themselves. It's a feature we have so that transient / occasional failures are auto-retried, but it's misfiring here because we're not detecting that it's a consistent failure. That particular bug is fixed, but it means that ocfs2-tools is failing on ppc64el. Here's the important part of the log, full output attached. [ 85.605738] BUG: Unable to handle kernel data access at 0x01744098 [ 85.605850] Faulting instruction address: 0xc0e81168 [ 85.605901] Oops: Kernel access of bad area, sig: 11 [#1] [ 85.605970] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries [ 85.606029] Modules linked in: ocfs2 quota_tree ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue iptable_mangle xt_TCPMSS xt_tcpudp bpfilter dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua vmx_crypto crct10dif_vpmsum sch_fq_codel ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq libcrc32c crc32c_vpmsum virtio_net virtio_blk net_failover failover [ 85.606291] CPU: 0 PID: 1 Comm: systemd Not tainted 5.3.0-18-generic #19-Ubuntu [ 85.606350] NIP: c0e81168 LR: c054f240 CTR: [ 85.606410] REGS: c0005a3e3700 TRAP: 0300 Not tainted (5.3.0-18-generic) [ 85.606469] MSR: 80009033 CR: 28024448 XER: [ 85.606531] CFAR: 701f9806f638 DAR: 01744098 DSISR: 4000 IRQMASK: 0 [ 85.606531] GPR00: 7374 c0005a3e3990 c19c9100 c0004fe462a8 [ 85.606531] GPR04: c0005856d840 000e 74656772 c0004fe4a568 [ 85.606531] GPR08: c00058568004 01744090 [ 85.606531] GPR12: e8086002 c1d6 7fffddd522d0 [ 85.606531] GPR16: c755e07c [ 85.606531] GPR20: c000598caca8 c0005a3e3a58 c00058292f00 [ 85.606531] GPR24: c0eea710 c0005856d840 c755e074 [ 85.606531] GPR28: 6518907d c0005a3e3a68 c0004fe4b160 027c47b6 [ 85.607079] NIP
[Kernel-packages] [Bug 1718227] Re: replacement of ifupdown with netplan needs integration for /etc/network/if{up, down}.d scripts
For openvpn + systemd-resolve:
With "up / down" openvpn config file commands you can wrap "systemd-
resolve --set-dns=XXX" and update the given DNS servers.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to ubuntu-fan in Ubuntu.
https://bugs.launchpad.net/bugs/1718227
Title:
replacement of ifupdown with netplan needs integration for
/etc/network/if{up,down}.d scripts
Status in aiccu package in Ubuntu:
Invalid
Status in aoetools package in Ubuntu:
New
Status in avahi package in Ubuntu:
New
Status in bind9 package in Ubuntu:
Invalid
Status in chrony package in Ubuntu:
Fix Released
Status in clamav package in Ubuntu:
Triaged
Status in controlaula package in Ubuntu:
Invalid
Status in ethtool package in Ubuntu:
Triaged
Status in guidedog package in Ubuntu:
New
Status in htpdate package in Ubuntu:
New
Status in ifenslave package in Ubuntu:
Won't Fix
Status in ifmetric package in Ubuntu:
Won't Fix
Status in ifupdown-multi package in Ubuntu:
New
Status in ifupdown-scripts-zg2 package in Ubuntu:
Invalid
Status in isatapd package in Ubuntu:
New
Status in lprng package in Ubuntu:
New
Status in miredo package in Ubuntu:
New
Status in mythtv package in Ubuntu:
New
Status in nplan package in Ubuntu:
New
Status in nss-pam-ldapd package in Ubuntu:
New
Status in ntp package in Ubuntu:
Won't Fix
Status in openntpd package in Ubuntu:
New
Status in openresolv package in Ubuntu:
Won't Fix
Status in openssh package in Ubuntu:
Fix Released
Status in openvpn package in Ubuntu:
Confirmed
Status in openvswitch package in Ubuntu:
Triaged
Status in postfix package in Ubuntu:
New
Status in quicktun package in Ubuntu:
New
Status in resolvconf package in Ubuntu:
New
Status in sendmail package in Ubuntu:
New
Status in shorewall-init package in Ubuntu:
New
Status in sidedoor package in Ubuntu:
New
Status in slrn package in Ubuntu:
New
Status in tinc package in Ubuntu:
New
Status in ubuntu-fan package in Ubuntu:
Fix Released
Status in ucarp package in Ubuntu:
New
Status in uml-utilities package in Ubuntu:
New
Status in uruk package in Ubuntu:
New
Status in vlan package in Ubuntu:
Won't Fix
Status in vzctl package in Ubuntu:
Triaged
Status in wide-dhcpv6 package in Ubuntu:
New
Status in wpa package in Ubuntu:
New
Bug description:
when network is configured with ifupdown, scripts in
/etc/network/ifup.d/ were called on network being brought up and
/etc/network/ifdown.d were called on network being brought down.
Any packages that shipped these hooks need to be verified to have the
same functionality under a netplan configured system.
# binpkgs=$(apt-file search /etc/network/if-up | sed 's,: .*,,' | sort -u)
# for i in $binpkgs; do
src=$(apt-cache show $i | awk '$1 == "Source:" { print $2; exit(0); }');
[ -z "$src" ] && src="$i"; echo $src; done | sort -u
aiccu
aoetools
avahi
bind9
chrony
clamav
controlaula
epoptes
ethtool
guidedog
htpdate
ifenslave
ifmetric
ifupdown-extra
ifupdown-multi
ifupdown-scripts-zg2
isatapd
lprng
miredo
mythtv-backend
nss-pam-ldapd
ntp
openntpd
openresolv
openssh
openvpn
postfix
quicktun
resolvconf
sendmail
shorewall-init
sidedoor
slrn
tinc
ubuntu-fan
ucarp
uml-utilities
uruk
vlan
vzctl
wide-dhcpv6
wpa
Related bugs:
* bug 1718227: replacement of ifupdown with netplan needs integration for
/etc/network/if{up,down}.d scripts
* bug 1713803: replacement of resolvconf with systemd needs integration
* bug 1717983: replacement of isc-dhcp-client with with systemd-networkd for
dhclient needs integration
ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: netplan (not installed)
ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5
Uname: Linux 4.12.0-11-generic x86_64
NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
ApportVersion: 2.20.7-0ubuntu1
Architecture: amd64
CurrentDesktop: GNOME
Date: Tue Sep 19 10:53:08 2017
EcryptfsInUse: Yes
InstallationDate: Installed on 2015-07-23 (789 days ago)
InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: plan
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1718227/+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 1718227] Re: replacement of ifupdown with netplan needs integration for /etc/network/if{up, down}.d scripts
An example of dns update after putting:
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
in the openvpn .config file:
Wed Dec 11 15:04:25 2019 /etc/openvpn/update-resolv-conf tun0 1500 1558
10.172.67.194 255.255.192.0 init
update-resolv-conf uses:
[ -x /sbin/resolvconf ] || exit 0
so I guess it needs a systemd-resolved.service integration instead.
** Changed in: openvpn (Ubuntu)
Importance: Undecided => Medium
** Changed in: openvpn (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to ubuntu-fan in Ubuntu.
https://bugs.launchpad.net/bugs/1718227
Title:
replacement of ifupdown with netplan needs integration for
/etc/network/if{up,down}.d scripts
Status in aiccu package in Ubuntu:
Invalid
Status in aoetools package in Ubuntu:
New
Status in avahi package in Ubuntu:
New
Status in bind9 package in Ubuntu:
Invalid
Status in chrony package in Ubuntu:
Fix Released
Status in clamav package in Ubuntu:
Triaged
Status in controlaula package in Ubuntu:
Invalid
Status in ethtool package in Ubuntu:
Triaged
Status in guidedog package in Ubuntu:
New
Status in htpdate package in Ubuntu:
New
Status in ifenslave package in Ubuntu:
Won't Fix
Status in ifmetric package in Ubuntu:
Won't Fix
Status in ifupdown-multi package in Ubuntu:
New
Status in ifupdown-scripts-zg2 package in Ubuntu:
Invalid
Status in isatapd package in Ubuntu:
New
Status in lprng package in Ubuntu:
New
Status in miredo package in Ubuntu:
New
Status in mythtv package in Ubuntu:
New
Status in nplan package in Ubuntu:
New
Status in nss-pam-ldapd package in Ubuntu:
New
Status in ntp package in Ubuntu:
Won't Fix
Status in openntpd package in Ubuntu:
New
Status in openresolv package in Ubuntu:
Won't Fix
Status in openssh package in Ubuntu:
Fix Released
Status in openvpn package in Ubuntu:
Confirmed
Status in openvswitch package in Ubuntu:
Triaged
Status in postfix package in Ubuntu:
New
Status in quicktun package in Ubuntu:
New
Status in resolvconf package in Ubuntu:
New
Status in sendmail package in Ubuntu:
New
Status in shorewall-init package in Ubuntu:
New
Status in sidedoor package in Ubuntu:
New
Status in slrn package in Ubuntu:
New
Status in tinc package in Ubuntu:
New
Status in ubuntu-fan package in Ubuntu:
Fix Released
Status in ucarp package in Ubuntu:
New
Status in uml-utilities package in Ubuntu:
New
Status in uruk package in Ubuntu:
New
Status in vlan package in Ubuntu:
Won't Fix
Status in vzctl package in Ubuntu:
Triaged
Status in wide-dhcpv6 package in Ubuntu:
New
Status in wpa package in Ubuntu:
New
Bug description:
when network is configured with ifupdown, scripts in
/etc/network/ifup.d/ were called on network being brought up and
/etc/network/ifdown.d were called on network being brought down.
Any packages that shipped these hooks need to be verified to have the
same functionality under a netplan configured system.
# binpkgs=$(apt-file search /etc/network/if-up | sed 's,: .*,,' | sort -u)
# for i in $binpkgs; do
src=$(apt-cache show $i | awk '$1 == "Source:" { print $2; exit(0); }');
[ -z "$src" ] && src="$i"; echo $src; done | sort -u
aiccu
aoetools
avahi
bind9
chrony
clamav
controlaula
epoptes
ethtool
guidedog
htpdate
ifenslave
ifmetric
ifupdown-extra
ifupdown-multi
ifupdown-scripts-zg2
isatapd
lprng
miredo
mythtv-backend
nss-pam-ldapd
ntp
openntpd
openresolv
openssh
openvpn
postfix
quicktun
resolvconf
sendmail
shorewall-init
sidedoor
slrn
tinc
ubuntu-fan
ucarp
uml-utilities
uruk
vlan
vzctl
wide-dhcpv6
wpa
Related bugs:
* bug 1718227: replacement of ifupdown with netplan needs integration for
/etc/network/if{up,down}.d scripts
* bug 1713803: replacement of resolvconf with systemd needs integration
* bug 1717983: replacement of isc-dhcp-client with with systemd-networkd for
dhclient needs integration
ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: netplan (not installed)
ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5
Uname: Linux 4.12.0-11-generic x86_64
NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
ApportVersion: 2.20.7-0ubuntu1
Architecture: amd64
CurrentDesktop: GNOME
Date: Tue Sep 19 10:53:08 2017
EcryptfsInUse: Yes
InstallationDate: Installed on 2015-07-23 (789 days ago)
InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: plan
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1718227/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to :
[Kernel-packages] [Bug 1855177] Re: QEMU emulated nvdimm regions alignment need (128MB) or ndctl create-namespace namespace1.0 might fail
You have to make sure to set the label size as the same size as the minimum alignment required. For QEMU emulation I found it to be 2M, and, in this case, you can correctly work with 2 or more nvdimms. With proper alignment, you can also re-create namespaces - of other mode like devdax or fsdax - if you already have a namespace working. Example: $_nvpath1 1048576 0 2048 $_nvpath2 1048576 1 2048 So I'm closing this as NOT A BUG as the alignment can be configured accordingly. For other examples you can check autopkgtests being proposed as a merge request at: https://bugs.launchpad.net/ubuntu/+source/ndctl/+bug/1853506 ** Changed in: ndctl (Ubuntu Focal) Status: Confirmed => Invalid ** Changed in: qemu (Ubuntu Focal) Status: Confirmed => 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/1855177 Title: QEMU emulated nvdimm regions alignment need (128MB) or ndctl create- namespace namespace1.0 might fail Status in linux package in Ubuntu: Fix Released Status in ndctl package in Ubuntu: Invalid Status in qemu package in Ubuntu: Invalid Status in linux source package in Focal: Fix Released Status in ndctl source package in Focal: Invalid Status in qemu source package in Focal: Invalid Bug description: I got a probe error for pfn1.0 (from both pfn0.0 and pfn1.0) when dealing with ndctl: [11257.765457] memory add fail, invalid altmap [11257.765489] WARNING: CPU: 6 PID: 5680 at arch/x86/mm/init_64.c:852 add_pages+0x5d/0x70 [11257.765489] Modules linked in: nls_iso8859_1 edac_mce_amd crct10dif_pclmul crc32_pclmul dax_pmem_compat device_dax dax_pmem_core nd_pmem nd_btt ghash_clmulni_intel aesni_intel aes_x86_64 crypto_simd cryptd glue_helper input_leds joydev mac_hid nfit serio_raw qemu_fw_cfg sch_fq_codel ip_tables x_tables autofs4 virtio_net net_failover psmouse failover pata_acpi virtio_blk i2c_piix4 floppy [11257.765505] CPU: 6 PID: 5680 Comm: ndctl Not tainted 5.3.0-24-generic #26-Ubuntu [11257.765505] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 [11257.765507] RIP: 0010:add_pages+0x5d/0x70 [11257.765509] Code: 33 c2 01 76 20 48 89 15 99 33 c2 01 48 89 15 a2 33 c2 01 48 c1 e2 0c 48 03 15 97 96 39 01 48 89 15 48 0e c2 01 5b 41 5c 5d c3 <0f> 0b eb ba 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 [11257.765509] RSP: 0018:a360c09dfbf0 EFLAGS: 00010282 [11257.765510] RAX: ffea RBX: 0017ffe0 RCX: [11257.765511] RDX: RSI: 8acb7db17448 RDI: 8acb7db17448 [11257.765512] RBP: a360c09dfc00 R08: 8acb7db17448 R09: 0004 [11257.765512] R10: R11: 0001 R12: 0003fe20 [11257.765513] R13: 0001 R14: a360c09dfc48 R15: 8acb7a7226f8 [11257.765515] FS: 7febc9fd6bc0() GS:8acb7db0() knlGS: [11257.765516] CS: 0010 DS: ES: CR0: 80050033 [11257.765517] CR2: 55eec8aab398 CR3: 00013a8fa000 CR4: 000406e0 [11257.765519] Call Trace: [11257.765523] arch_add_memory+0x41/0x50 [11257.765525] devm_memremap_pages+0x47c/0x640 [11257.765529] pmem_attach_disk+0x173/0x610 [nd_pmem] [11257.765531] ? devm_memremap+0x67/0xa0 [11257.765532] nd_pmem_probe+0x7f/0xa0 [nd_pmem] [11257.765542] nvdimm_bus_probe+0x6b/0x170 [11257.765547] really_probe+0xfb/0x3a0 [11257.765549] driver_probe_device+0x5f/0xe0 [11257.765550] device_driver_attach+0x5d/0x70 [11257.765551] bind_store+0xd3/0x110 [11257.765553] drv_attr_store+0x24/0x30 [11257.765554] sysfs_kf_write+0x3e/0x50 [11257.76] kernfs_fop_write+0x11e/0x1a0 [11257.765557] __vfs_write+0x1b/0x40 [11257.765558] vfs_write+0xb9/0x1a0 [11257.765559] ksys_write+0x67/0xe0 [11257.765561] __x64_sys_write+0x1a/0x20 [11257.765567] do_syscall_64+0x5a/0x130 [11257.765693] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [11257.765696] RIP: 0033:0x7febc9e81327 [11257.765698] Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 [11257.765698] RSP: 002b:7ffd599433f8 EFLAGS: 0246 ORIG_RAX: 0001 [11257.765699] RAX: ffda RBX: 7febc9fd6ae8 RCX: 7febc9e81327 [11257.765700] RDX: 0007 RSI: 55eec8a9bfa0 RDI: 0004 [11257.765701] RBP: 0004 R08: 0006 R09: 7375622f7379732f [11257.765701] R10: R11: 0246 R12: 55eec8a9bfa0 [11257.765702] R13:
[Kernel-packages] [Bug 1855177] Re: QEMU emulated nvdimm regions alignment need (128MB) or ndctl create-namespace namespace1.0 might fail
>From comment #5, i was able to make changes persistent with
access='shared':
/tmp/.nbdpath1.2898617
1048576
0
256
so now backing files are updated (and can even be shared among 2 vms).
--
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/1855177
Title:
QEMU emulated nvdimm regions alignment need (128MB) or ndctl create-
namespace namespace1.0 might fail
Status in linux package in Ubuntu:
Fix Released
Status in ndctl package in Ubuntu:
Confirmed
Status in qemu package in Ubuntu:
Confirmed
Status in linux source package in Focal:
Fix Released
Status in ndctl source package in Focal:
Confirmed
Status in qemu source package in Focal:
Confirmed
Bug description:
I got a probe error for pfn1.0 (from both pfn0.0 and pfn1.0) when
dealing with ndctl:
[11257.765457] memory add fail, invalid altmap
[11257.765489] WARNING: CPU: 6 PID: 5680 at arch/x86/mm/init_64.c:852
add_pages+0x5d/0x70
[11257.765489] Modules linked in: nls_iso8859_1 edac_mce_amd crct10dif_pclmul
crc32_pclmul dax_pmem_compat device_dax dax_pmem_core nd_pmem nd_btt
ghash_clmulni_intel aesni_intel aes_x86_64 crypto_simd cryptd glue_helper
input_leds joydev mac_hid nfit serio_raw qemu_fw_cfg sch_fq_codel ip_tables
x_tables autofs4 virtio_net net_failover psmouse failover pata_acpi virtio_blk
i2c_piix4 floppy
[11257.765505] CPU: 6 PID: 5680 Comm: ndctl Not tainted 5.3.0-24-generic
#26-Ubuntu
[11257.765505] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.12.0-1 04/01/2014
[11257.765507] RIP: 0010:add_pages+0x5d/0x70
[11257.765509] Code: 33 c2 01 76 20 48 89 15 99 33 c2 01 48 89 15 a2 33 c2 01
48 c1 e2 0c 48 03 15 97 96 39 01 48 89 15 48 0e c2 01 5b 41 5c 5d c3 <0f> 0b eb
ba 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44
[11257.765509] RSP: 0018:a360c09dfbf0 EFLAGS: 00010282
[11257.765510] RAX: ffea RBX: 0017ffe0 RCX:
[11257.765511] RDX: RSI: 8acb7db17448 RDI:
8acb7db17448
[11257.765512] RBP: a360c09dfc00 R08: 8acb7db17448 R09:
0004
[11257.765512] R10: R11: 0001 R12:
0003fe20
[11257.765513] R13: 0001 R14: a360c09dfc48 R15:
8acb7a7226f8
[11257.765515] FS: 7febc9fd6bc0() GS:8acb7db0()
knlGS:
[11257.765516] CS: 0010 DS: ES: CR0: 80050033
[11257.765517] CR2: 55eec8aab398 CR3: 00013a8fa000 CR4:
000406e0
[11257.765519] Call Trace:
[11257.765523] arch_add_memory+0x41/0x50
[11257.765525] devm_memremap_pages+0x47c/0x640
[11257.765529] pmem_attach_disk+0x173/0x610 [nd_pmem]
[11257.765531] ? devm_memremap+0x67/0xa0
[11257.765532] nd_pmem_probe+0x7f/0xa0 [nd_pmem]
[11257.765542] nvdimm_bus_probe+0x6b/0x170
[11257.765547] really_probe+0xfb/0x3a0
[11257.765549] driver_probe_device+0x5f/0xe0
[11257.765550] device_driver_attach+0x5d/0x70
[11257.765551] bind_store+0xd3/0x110
[11257.765553] drv_attr_store+0x24/0x30
[11257.765554] sysfs_kf_write+0x3e/0x50
[11257.76] kernfs_fop_write+0x11e/0x1a0
[11257.765557] __vfs_write+0x1b/0x40
[11257.765558] vfs_write+0xb9/0x1a0
[11257.765559] ksys_write+0x67/0xe0
[11257.765561] __x64_sys_write+0x1a/0x20
[11257.765567] do_syscall_64+0x5a/0x130
[11257.765693] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[11257.765696] RIP: 0033:0x7febc9e81327
[11257.765698] Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00
f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00
f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
[11257.765698] RSP: 002b:7ffd599433f8 EFLAGS: 0246 ORIG_RAX:
0001
[11257.765699] RAX: ffda RBX: 7febc9fd6ae8 RCX:
7febc9e81327
[11257.765700] RDX: 0007 RSI: 55eec8a9bfa0 RDI:
0004
[11257.765701] RBP: 0004 R08: 0006 R09:
7375622f7379732f
[11257.765701] R10: R11: 0246 R12:
55eec8a9bfa0
[11257.765702] R13: 0001 R14: 0007 R15:
7ffd59943448
[11257.765703] ---[ end trace 442db04e33790cb5 ]---
[11257.782659] nd_pmem: probe of pfn1.0 failed with error -22
It seems that after this point I can't play with my second virtual
nvdimm device (pfn1.0).
A namespace destroy works but a namespace creation does not:
rafaeldtinoco@ndctltest:~$ sudo ndctl list -B
[
{
"provider":"ACPI.NFIT",
"dev":"ndbus0"
}
]
rafaeldtinoco@ndctltest:~$ sudo ndctl list -D
[
{
"dev":"nmem1",
"id":"8680-57341200",
"handle":2,
"phys_id":0
},
{
"dev":"nmem0",
"id":"8680-56341200",
[Kernel-packages] [Bug 1855177] Re: qemu nvdimm virtualization + linux 5.3.0-24-generic kernel PROBE ERROR
This way more complex than I thought and its not so easy to address. Lets see if I can summarize the issue here. Whenever developing the regressions tests for ndctl, it occurred to me the same backtrace, over and over, when realizing the tests: [ 271.705646] memory add fail, invalid altmap [ 271.705677] WARNING: CPU: 5 PID: 886 at arch/x86/mm/init_64.c:852 add_pages+0x5d/0x70 [ 271.705679] Modules linked in: nls_iso8859_1 edac_mce_amd dax_pmem_compat nd_pmem device_dax nd_btt dax_pmem_core crct10dif_pclmul crc32_pclmul ghash_clmulni_intel joydev aesni_intel aes_x86_64 crypto_simd input_leds cryptd glue_helper serio_raw mac_hid qemu_fw_cfg nfit sch_fq_codel ip_tables x_tables autofs4 virtio_net psmouse net_failover virtio_blk i2c_piix4 failover pata_acpi floppy [ 271.705707] CPU: 5 PID: 886 Comm: ndctl Not tainted 5.3.0-24-generic #26-Ubuntu [ 271.705709] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 [ 271.705720] RIP: 0010:add_pages+0x5d/0x70 [ 271.705721] Code: 33 c2 01 76 20 48 89 15 99 33 c2 01 48 89 15 a2 33 c2 01 48 c1 e2 0c 48 03 15 97 96 39 01 48 89 15 48 0e c2 01 5b 41 5c 5d c3 <0f> 0b eb ba 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 [ 271.705722] RSP: 0018:ba02c0d2bbf0 EFLAGS: 00010282 [ 271.705723] RAX: ffea RBX: 0017ffc0 RCX: [ 271.705723] RDX: RSI: 9aaa3da97448 RDI: 9aaa3da97448 [ 271.705724] RBP: ba02c0d2bc00 R08: 9aaa3da97448 R09: 0004 [ 271.705724] R10: R11: 0001 R12: 0003fe40 [ 271.705725] R13: 0001 R14: ba02c0d2bc48 R15: 9aa975efaaf8 [ 271.705727] FS: 7f70a62d4bc0() GS:9aaa3da8() knlGS: [ 271.705728] CS: 0010 DS: ES: CR0: 80050033 [ 271.705729] CR2: 5594a0aaa158 CR3: 00013811 CR4: 000406e0 [ 271.705731] Call Trace: [ 271.705734] arch_add_memory+0x41/0x50 [ 271.705737] devm_memremap_pages+0x47c/0x640 [ 271.705740] pmem_attach_disk+0x173/0x610 [nd_pmem] [ 271.705741] ? devm_memremap+0x67/0xa0 [ 271.705743] nd_pmem_probe+0x7f/0xa0 [nd_pmem] [ 271.705745] nvdimm_bus_probe+0x6b/0x170 [ 271.705747] really_probe+0xfb/0x3a0 [ 271.705749] driver_probe_device+0x5f/0xe0 [ 271.705750] device_driver_attach+0x5d/0x70 [ 271.705751] bind_store+0xd3/0x110 [ 271.705753] drv_attr_store+0x24/0x30 [ 271.705754] sysfs_kf_write+0x3e/0x50 [ 271.705755] kernfs_fop_write+0x11e/0x1a0 [ 271.705757] __vfs_write+0x1b/0x40 [ 271.705758] vfs_write+0xb9/0x1a0 [ 271.705759] ksys_write+0x67/0xe0 [ 271.705760] __x64_sys_write+0x1a/0x20 [ 271.705762] do_syscall_64+0x5a/0x130 [ 271.705764] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 271.705765] RIP: 0033:0x7f70a6189327 [ 271.705767] Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 [ 271.705767] RSP: 002b:7ffc616998b8 EFLAGS: 0246 ORIG_RAX: 0001 [ 271.705768] RAX: ffda RBX: 7f70a62d4ae8 RCX: 7f70a6189327 [ 271.705769] RDX: 0007 RSI: 5594a0aa01a0 RDI: 0006 [ 271.705769] RBP: 0006 R08: 0006 R09: 7375622f7379732f [ 271.705770] R10: R11: 0246 R12: 5594a0aa01a0 [ 271.705770] R13: 0001 R14: 0007 R15: 7ffc61699908 [ 271.705772] ---[ end trace 7ee621e68332018c ]--- And I realized that I could NOT re-generate the SECOND namespace (the first one always worked). First I had to read about how qemu emulated nvdimms and check why namespaces were not persistent on qemu nvdimms emulation, then I had to discover why it looked like virtual nvdimms had no labels (as RAW namespaces are always created by default) and then I had to understand why the mapping was failing, to realize the real issue. First things first. ### QEMU emulated nvdimms: https://github.com/qemu/qemu/blob/master/docs/nvdimm.txt Whenever backing filesystems are not DAX capable (on a REAL NVDIMM HW, for example) then after the instance is shutdown all nvdimm data (written to the backing files) are gone. ### QEMU virtual nvdimms lack of labels: Label - QEMU v2.7.0 and later implement the label support for vNVDIMM devices. To enable label on vNVDIMM devices, users can simply add "label-size=$SZ" option to "-device nvdimm", e.g. -device nvdimm,id=nvdimm1,memdev=mem1,label-size=128K Note: 1. The minimal label size is 128KB. 2. QEMU v2.7.0 and later store labels at the end of backend storage. If a memory backend file, which was previously used as the backend of a vNVDIMM device without labels, is now used for a vNVDIMM device with label, the data in the label area at the end of file will be inaccessible to the guest. If any useful data (e.g. the meta-data of
[Kernel-packages] [Bug 1855177] Re: QEMU emulated nvdimm regions alignment need (128MB) or ndctl create-namespace namespace1.0 might fail
The Linux Kernel fix is here:
commit 274b924088e9
Author: Jeff Moyer
Date: Wed Aug 28 12:49:46 2019
libnvdimm/pfn: Fix namespace creation on misaligned addresses
Yi reported[1] that after commit a3619190d62e ("libnvdimm/pfn: stop
padding pmem namespaces to section alignment"), it was no longer
possible to create a device dax namespace with a 1G alignment. The
reason was that the pmem region was not itself 1G-aligned. The code
happily skips past the first 512M, but fails to account for a now
misaligned end offset (since space was allocated starting at that
misaligned address, and extending for size GBs). Reintroduce
end_trunc, so that the code correctly handles the misaligned end
address. This results in the same behavior as before the introduction
of the offending commit.
[1] https://lists.01.org/pipermail/linux-nvdimm/2019-July/022813.html
Fixes: a3619190d62e ("libnvdimm/pfn: stop padding pmem namespaces ...")
Reported-and-tested-by: Yi Zhang
Signed-off-by: Jeff Moyer
Link:
https://lore.kernel.org/r/x49ftll8f39@segfault.boston.devel.redhat.com
Signed-off-by: Dan Williams
So marking kernel as Fix Released (as this is included in Focal).
** Also affects: qemu (Ubuntu Focal)
Importance: Medium
Status: Confirmed
** Also affects: linux (Ubuntu Focal)
Importance: Medium
Status: Fix Released
** Also affects: ndctl (Ubuntu Focal)
Importance: Medium
Status: 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/1855177
Title:
QEMU emulated nvdimm regions alignment need (128MB) or ndctl create-
namespace namespace1.0 might fail
Status in linux package in Ubuntu:
Fix Released
Status in ndctl package in Ubuntu:
Confirmed
Status in qemu package in Ubuntu:
Confirmed
Status in linux source package in Focal:
Fix Released
Status in ndctl source package in Focal:
Confirmed
Status in qemu source package in Focal:
Confirmed
Bug description:
I got a probe error for pfn1.0 (from both pfn0.0 and pfn1.0) when
dealing with ndctl:
[11257.765457] memory add fail, invalid altmap
[11257.765489] WARNING: CPU: 6 PID: 5680 at arch/x86/mm/init_64.c:852
add_pages+0x5d/0x70
[11257.765489] Modules linked in: nls_iso8859_1 edac_mce_amd crct10dif_pclmul
crc32_pclmul dax_pmem_compat device_dax dax_pmem_core nd_pmem nd_btt
ghash_clmulni_intel aesni_intel aes_x86_64 crypto_simd cryptd glue_helper
input_leds joydev mac_hid nfit serio_raw qemu_fw_cfg sch_fq_codel ip_tables
x_tables autofs4 virtio_net net_failover psmouse failover pata_acpi virtio_blk
i2c_piix4 floppy
[11257.765505] CPU: 6 PID: 5680 Comm: ndctl Not tainted 5.3.0-24-generic
#26-Ubuntu
[11257.765505] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.12.0-1 04/01/2014
[11257.765507] RIP: 0010:add_pages+0x5d/0x70
[11257.765509] Code: 33 c2 01 76 20 48 89 15 99 33 c2 01 48 89 15 a2 33 c2 01
48 c1 e2 0c 48 03 15 97 96 39 01 48 89 15 48 0e c2 01 5b 41 5c 5d c3 <0f> 0b eb
ba 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44
[11257.765509] RSP: 0018:a360c09dfbf0 EFLAGS: 00010282
[11257.765510] RAX: ffea RBX: 0017ffe0 RCX:
[11257.765511] RDX: RSI: 8acb7db17448 RDI:
8acb7db17448
[11257.765512] RBP: a360c09dfc00 R08: 8acb7db17448 R09:
0004
[11257.765512] R10: R11: 0001 R12:
0003fe20
[11257.765513] R13: 0001 R14: a360c09dfc48 R15:
8acb7a7226f8
[11257.765515] FS: 7febc9fd6bc0() GS:8acb7db0()
knlGS:
[11257.765516] CS: 0010 DS: ES: CR0: 80050033
[11257.765517] CR2: 55eec8aab398 CR3: 00013a8fa000 CR4:
000406e0
[11257.765519] Call Trace:
[11257.765523] arch_add_memory+0x41/0x50
[11257.765525] devm_memremap_pages+0x47c/0x640
[11257.765529] pmem_attach_disk+0x173/0x610 [nd_pmem]
[11257.765531] ? devm_memremap+0x67/0xa0
[11257.765532] nd_pmem_probe+0x7f/0xa0 [nd_pmem]
[11257.765542] nvdimm_bus_probe+0x6b/0x170
[11257.765547] really_probe+0xfb/0x3a0
[11257.765549] driver_probe_device+0x5f/0xe0
[11257.765550] device_driver_attach+0x5d/0x70
[11257.765551] bind_store+0xd3/0x110
[11257.765553] drv_attr_store+0x24/0x30
[11257.765554] sysfs_kf_write+0x3e/0x50
[11257.76] kernfs_fop_write+0x11e/0x1a0
[11257.765557] __vfs_write+0x1b/0x40
[11257.765558] vfs_write+0xb9/0x1a0
[11257.765559] ksys_write+0x67/0xe0
[11257.765561] __x64_sys_write+0x1a/0x20
[11257.765567] do_syscall_64+0x5a/0x130
[11257.765693] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[11257.765696] RIP: 0033:0x7febc9e81327
[11257.765698] Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00
f3 0f 1e fa 64 8b 04 25 18 00 00 00 85
[Kernel-packages] [Bug 1855177] Re: qemu nvdimm virtualization + linux 5.3.0-24-generic kernel PROBE ERROR
** No longer affects: linux (Ubuntu Focal)
** Also affects: ndctl (Ubuntu)
Importance: Undecided
Status: New
** Changed in: ndctl (Ubuntu)
Status: New => Confirmed
** Changed in: qemu (Ubuntu Focal)
Status: Invalid => Confirmed
** Changed in: linux (Ubuntu)
Status: Invalid => Confirmed
** No longer affects: qemu (Ubuntu Focal)
** Changed in: ndctl (Ubuntu)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu)
Importance: Low => Medium
** Changed in: qemu (Ubuntu)
Importance: Low => Medium
--
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/1855177
Title:
qemu nvdimm virtualization + linux 5.3.0-24-generic kernel PROBE ERROR
Status in linux package in Ubuntu:
Confirmed
Status in ndctl package in Ubuntu:
Confirmed
Status in qemu package in Ubuntu:
Confirmed
Bug description:
I got a probe error for pfn1.0 (from both pfn0.0 and pfn1.0) when
dealing with ndctl:
[11257.765457] memory add fail, invalid altmap
[11257.765489] WARNING: CPU: 6 PID: 5680 at arch/x86/mm/init_64.c:852
add_pages+0x5d/0x70
[11257.765489] Modules linked in: nls_iso8859_1 edac_mce_amd crct10dif_pclmul
crc32_pclmul dax_pmem_compat device_dax dax_pmem_core nd_pmem nd_btt
ghash_clmulni_intel aesni_intel aes_x86_64 crypto_simd cryptd glue_helper
input_leds joydev mac_hid nfit serio_raw qemu_fw_cfg sch_fq_codel ip_tables
x_tables autofs4 virtio_net net_failover psmouse failover pata_acpi virtio_blk
i2c_piix4 floppy
[11257.765505] CPU: 6 PID: 5680 Comm: ndctl Not tainted 5.3.0-24-generic
#26-Ubuntu
[11257.765505] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.12.0-1 04/01/2014
[11257.765507] RIP: 0010:add_pages+0x5d/0x70
[11257.765509] Code: 33 c2 01 76 20 48 89 15 99 33 c2 01 48 89 15 a2 33 c2 01
48 c1 e2 0c 48 03 15 97 96 39 01 48 89 15 48 0e c2 01 5b 41 5c 5d c3 <0f> 0b eb
ba 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44
[11257.765509] RSP: 0018:a360c09dfbf0 EFLAGS: 00010282
[11257.765510] RAX: ffea RBX: 0017ffe0 RCX:
[11257.765511] RDX: RSI: 8acb7db17448 RDI:
8acb7db17448
[11257.765512] RBP: a360c09dfc00 R08: 8acb7db17448 R09:
0004
[11257.765512] R10: R11: 0001 R12:
0003fe20
[11257.765513] R13: 0001 R14: a360c09dfc48 R15:
8acb7a7226f8
[11257.765515] FS: 7febc9fd6bc0() GS:8acb7db0()
knlGS:
[11257.765516] CS: 0010 DS: ES: CR0: 80050033
[11257.765517] CR2: 55eec8aab398 CR3: 00013a8fa000 CR4:
000406e0
[11257.765519] Call Trace:
[11257.765523] arch_add_memory+0x41/0x50
[11257.765525] devm_memremap_pages+0x47c/0x640
[11257.765529] pmem_attach_disk+0x173/0x610 [nd_pmem]
[11257.765531] ? devm_memremap+0x67/0xa0
[11257.765532] nd_pmem_probe+0x7f/0xa0 [nd_pmem]
[11257.765542] nvdimm_bus_probe+0x6b/0x170
[11257.765547] really_probe+0xfb/0x3a0
[11257.765549] driver_probe_device+0x5f/0xe0
[11257.765550] device_driver_attach+0x5d/0x70
[11257.765551] bind_store+0xd3/0x110
[11257.765553] drv_attr_store+0x24/0x30
[11257.765554] sysfs_kf_write+0x3e/0x50
[11257.76] kernfs_fop_write+0x11e/0x1a0
[11257.765557] __vfs_write+0x1b/0x40
[11257.765558] vfs_write+0xb9/0x1a0
[11257.765559] ksys_write+0x67/0xe0
[11257.765561] __x64_sys_write+0x1a/0x20
[11257.765567] do_syscall_64+0x5a/0x130
[11257.765693] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[11257.765696] RIP: 0033:0x7febc9e81327
[11257.765698] Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00
f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00
f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
[11257.765698] RSP: 002b:7ffd599433f8 EFLAGS: 0246 ORIG_RAX:
0001
[11257.765699] RAX: ffda RBX: 7febc9fd6ae8 RCX:
7febc9e81327
[11257.765700] RDX: 0007 RSI: 55eec8a9bfa0 RDI:
0004
[11257.765701] RBP: 0004 R08: 0006 R09:
7375622f7379732f
[11257.765701] R10: R11: 0246 R12:
55eec8a9bfa0
[11257.765702] R13: 0001 R14: 0007 R15:
7ffd59943448
[11257.765703] ---[ end trace 442db04e33790cb5 ]---
[11257.782659] nd_pmem: probe of pfn1.0 failed with error -22
It seems that after this point I can't play with my second virtual
nvdimm device (pfn1.0).
A namespace destroy works but a namespace creation does not:
rafaeldtinoco@ndctltest:~$ sudo ndctl list -B
[
{
"provider":"ACPI.NFIT",
"dev":"ndbus0"
}
]
rafaeldtinoco@ndctltest:~$ sudo ndctl list -D
[
{
"dev":"nmem1",
"id":"8680-57341200",
"handle":2,
"phys_id":0
},
[Kernel-packages] [Bug 1855177] Re: qemu nvdimm virtualization + linux 5.3.0-24-generic kernel PROBE ERROR
Alright, if someone ever faces this, the label size can be the one to
blame.
Judging by the manual:
https://github.com/qemu/qemu/blob/master/docs/nvdimm.txt
Note:
1. The minimal label size is 128KB.
2. QEMU v2.7.0 and later store labels at the end of backend storage.
If a memory backend file, which was previously used as the backend
of a vNVDIMM device without labels, is now used for a vNVDIMM
device with label, the data in the label area at the end of file
will be inaccessible to the guest. If any useful data (e.g. the
meta-data of the file system) was stored there, the latter usage
may result guest data corruption (e.g. breakage of guest file
system).
=> 128KB was not enough. Changing label area to 2MB "fixed" the issue.
Funny is that I'm not even trying to use labels, I'm using full regions
for namespaces BUT its likely that there is a single label in those
cases (being written at the end of backing files).
=> I was also truncating the backing files, now I'm creating full zeroed
files (I guess that for the MMIO nature of DAX & PMEM, having full files
is either better OR mandatory).
rafaeldtinoco@ndctltest:~$ sudo ndctl disable-namespace all
disabled 2 namespaces
rafaeldtinoco@ndctltest:~$ sudo ndctl create-namespace -v -r region1 -m fsdax
{
"dev":"namespace1.0",
"mode":"fsdax",
"map":"dev",
"size":"1006.00 MiB (1054.87 MB)",
"uuid":"51dec4e0-1414-418a-9263-6459d5c12194",
"sector_size":512,
"align":2097152,
"blockdev":"pmem1"
}
rafaeldtinoco@ndctltest:~$ sudo ndctl create-namespace -v -r region0 -m fsdax
{
"dev":"namespace0.0",
"mode":"fsdax",
"map":"dev",
"size":"1006.00 MiB (1054.87 MB)",
"uuid":"33be9543-603c-4a7f-9f2d-98a3f3ff5ec0",
"sector_size":512,
"align":2097152,
"blockdev":"pmem0"
}
** Changed in: linux (Ubuntu Focal)
Status: Confirmed => Invalid
** Changed in: qemu (Ubuntu Focal)
Status: Confirmed => 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/1855177
Title:
qemu nvdimm virtualization + linux 5.3.0-24-generic kernel PROBE ERROR
Status in linux package in Ubuntu:
Invalid
Status in qemu package in Ubuntu:
Invalid
Status in linux source package in Focal:
Invalid
Status in qemu source package in Focal:
Invalid
Bug description:
I got a probe error for pfn1.0 (from both pfn0.0 and pfn1.0) when
dealing with ndctl:
[11257.765457] memory add fail, invalid altmap
[11257.765489] WARNING: CPU: 6 PID: 5680 at arch/x86/mm/init_64.c:852
add_pages+0x5d/0x70
[11257.765489] Modules linked in: nls_iso8859_1 edac_mce_amd crct10dif_pclmul
crc32_pclmul dax_pmem_compat device_dax dax_pmem_core nd_pmem nd_btt
ghash_clmulni_intel aesni_intel aes_x86_64 crypto_simd cryptd glue_helper
input_leds joydev mac_hid nfit serio_raw qemu_fw_cfg sch_fq_codel ip_tables
x_tables autofs4 virtio_net net_failover psmouse failover pata_acpi virtio_blk
i2c_piix4 floppy
[11257.765505] CPU: 6 PID: 5680 Comm: ndctl Not tainted 5.3.0-24-generic
#26-Ubuntu
[11257.765505] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.12.0-1 04/01/2014
[11257.765507] RIP: 0010:add_pages+0x5d/0x70
[11257.765509] Code: 33 c2 01 76 20 48 89 15 99 33 c2 01 48 89 15 a2 33 c2 01
48 c1 e2 0c 48 03 15 97 96 39 01 48 89 15 48 0e c2 01 5b 41 5c 5d c3 <0f> 0b eb
ba 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44
[11257.765509] RSP: 0018:a360c09dfbf0 EFLAGS: 00010282
[11257.765510] RAX: ffea RBX: 0017ffe0 RCX:
[11257.765511] RDX: RSI: 8acb7db17448 RDI:
8acb7db17448
[11257.765512] RBP: a360c09dfc00 R08: 8acb7db17448 R09:
0004
[11257.765512] R10: R11: 0001 R12:
0003fe20
[11257.765513] R13: 0001 R14: a360c09dfc48 R15:
8acb7a7226f8
[11257.765515] FS: 7febc9fd6bc0() GS:8acb7db0()
knlGS:
[11257.765516] CS: 0010 DS: ES: CR0: 80050033
[11257.765517] CR2: 55eec8aab398 CR3: 00013a8fa000 CR4:
000406e0
[11257.765519] Call Trace:
[11257.765523] arch_add_memory+0x41/0x50
[11257.765525] devm_memremap_pages+0x47c/0x640
[11257.765529] pmem_attach_disk+0x173/0x610 [nd_pmem]
[11257.765531] ? devm_memremap+0x67/0xa0
[11257.765532] nd_pmem_probe+0x7f/0xa0 [nd_pmem]
[11257.765542] nvdimm_bus_probe+0x6b/0x170
[11257.765547] really_probe+0xfb/0x3a0
[11257.765549] driver_probe_device+0x5f/0xe0
[11257.765550] device_driver_attach+0x5d/0x70
[11257.765551] bind_store+0xd3/0x110
[11257.765553] drv_attr_store+0x24/0x30
[11257.765554] sysfs_kf_write+0x3e/0x50
[11257.76] kernfs_fop_write+0x11e/0x1a0
[11257.765557] __vfs_write+0x1b/0x40
[11257.765558] vfs_write+0xb9/0x1a0
[11257.765559] ksys_write+0x67/0xe0
[11257.765561]
[Kernel-packages] [Bug 1855177] Re: qemu nvdimm virtualization + linux 5.3.0-24-generic kernel PROBE ERROR
Something else is wrong.. can't plan with the second nvdimm even after
re-creating the nvdimm backing files. I'm investigating.
--
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/1855177
Title:
qemu nvdimm virtualization + linux 5.3.0-24-generic kernel PROBE ERROR
Status in linux package in Ubuntu:
Confirmed
Status in qemu package in Ubuntu:
Confirmed
Status in linux source package in Focal:
Confirmed
Status in qemu source package in Focal:
Confirmed
Bug description:
I got a probe error for pfn1.0 (from both pfn0.0 and pfn1.0) when
dealing with ndctl:
[11257.765457] memory add fail, invalid altmap
[11257.765489] WARNING: CPU: 6 PID: 5680 at arch/x86/mm/init_64.c:852
add_pages+0x5d/0x70
[11257.765489] Modules linked in: nls_iso8859_1 edac_mce_amd crct10dif_pclmul
crc32_pclmul dax_pmem_compat device_dax dax_pmem_core nd_pmem nd_btt
ghash_clmulni_intel aesni_intel aes_x86_64 crypto_simd cryptd glue_helper
input_leds joydev mac_hid nfit serio_raw qemu_fw_cfg sch_fq_codel ip_tables
x_tables autofs4 virtio_net net_failover psmouse failover pata_acpi virtio_blk
i2c_piix4 floppy
[11257.765505] CPU: 6 PID: 5680 Comm: ndctl Not tainted 5.3.0-24-generic
#26-Ubuntu
[11257.765505] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.12.0-1 04/01/2014
[11257.765507] RIP: 0010:add_pages+0x5d/0x70
[11257.765509] Code: 33 c2 01 76 20 48 89 15 99 33 c2 01 48 89 15 a2 33 c2 01
48 c1 e2 0c 48 03 15 97 96 39 01 48 89 15 48 0e c2 01 5b 41 5c 5d c3 <0f> 0b eb
ba 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44
[11257.765509] RSP: 0018:a360c09dfbf0 EFLAGS: 00010282
[11257.765510] RAX: ffea RBX: 0017ffe0 RCX:
[11257.765511] RDX: RSI: 8acb7db17448 RDI:
8acb7db17448
[11257.765512] RBP: a360c09dfc00 R08: 8acb7db17448 R09:
0004
[11257.765512] R10: R11: 0001 R12:
0003fe20
[11257.765513] R13: 0001 R14: a360c09dfc48 R15:
8acb7a7226f8
[11257.765515] FS: 7febc9fd6bc0() GS:8acb7db0()
knlGS:
[11257.765516] CS: 0010 DS: ES: CR0: 80050033
[11257.765517] CR2: 55eec8aab398 CR3: 00013a8fa000 CR4:
000406e0
[11257.765519] Call Trace:
[11257.765523] arch_add_memory+0x41/0x50
[11257.765525] devm_memremap_pages+0x47c/0x640
[11257.765529] pmem_attach_disk+0x173/0x610 [nd_pmem]
[11257.765531] ? devm_memremap+0x67/0xa0
[11257.765532] nd_pmem_probe+0x7f/0xa0 [nd_pmem]
[11257.765542] nvdimm_bus_probe+0x6b/0x170
[11257.765547] really_probe+0xfb/0x3a0
[11257.765549] driver_probe_device+0x5f/0xe0
[11257.765550] device_driver_attach+0x5d/0x70
[11257.765551] bind_store+0xd3/0x110
[11257.765553] drv_attr_store+0x24/0x30
[11257.765554] sysfs_kf_write+0x3e/0x50
[11257.76] kernfs_fop_write+0x11e/0x1a0
[11257.765557] __vfs_write+0x1b/0x40
[11257.765558] vfs_write+0xb9/0x1a0
[11257.765559] ksys_write+0x67/0xe0
[11257.765561] __x64_sys_write+0x1a/0x20
[11257.765567] do_syscall_64+0x5a/0x130
[11257.765693] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[11257.765696] RIP: 0033:0x7febc9e81327
[11257.765698] Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00
f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00
f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
[11257.765698] RSP: 002b:7ffd599433f8 EFLAGS: 0246 ORIG_RAX:
0001
[11257.765699] RAX: ffda RBX: 7febc9fd6ae8 RCX:
7febc9e81327
[11257.765700] RDX: 0007 RSI: 55eec8a9bfa0 RDI:
0004
[11257.765701] RBP: 0004 R08: 0006 R09:
7375622f7379732f
[11257.765701] R10: R11: 0246 R12:
55eec8a9bfa0
[11257.765702] R13: 0001 R14: 0007 R15:
7ffd59943448
[11257.765703] ---[ end trace 442db04e33790cb5 ]---
[11257.782659] nd_pmem: probe of pfn1.0 failed with error -22
It seems that after this point I can't play with my second virtual
nvdimm device (pfn1.0).
A namespace destroy works but a namespace creation does not:
rafaeldtinoco@ndctltest:~$ sudo ndctl list -B
[
{
"provider":"ACPI.NFIT",
"dev":"ndbus0"
}
]
rafaeldtinoco@ndctltest:~$ sudo ndctl list -D
[
{
"dev":"nmem1",
"id":"8680-57341200",
"handle":2,
"phys_id":0
},
{
"dev":"nmem0",
"id":"8680-56341200",
"handle":1,
"phys_id":0
}
]
rafaeldtinoco@ndctltest:~$ sudo ndctl list -R
[
{
"dev":"region1",
"size":1073610752,
"available_size":1073610752,
"max_available_extent":1073610752,
"type":"pmem",
"iset_id":52512795602891997,
[Kernel-packages] [Bug 1855177] Re: qemu nvdimm virtualization + linux 5.3.0-24-generic kernel PROBE ERROR
Even after restart the kernel module the error continues, suggesting the
emulation is likely the root cause.
--
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/1855177
Title:
qemu nvdimm virtualization + linux 5.3.0-24-generic kernel PROBE ERROR
Status in linux package in Ubuntu:
Confirmed
Status in qemu package in Ubuntu:
Confirmed
Status in linux source package in Focal:
Confirmed
Status in qemu source package in Focal:
Confirmed
Bug description:
I got a probe error for pfn1.0 (from both pfn0.0 and pfn1.0) when
dealing with ndctl:
[11257.765457] memory add fail, invalid altmap
[11257.765489] WARNING: CPU: 6 PID: 5680 at arch/x86/mm/init_64.c:852
add_pages+0x5d/0x70
[11257.765489] Modules linked in: nls_iso8859_1 edac_mce_amd crct10dif_pclmul
crc32_pclmul dax_pmem_compat device_dax dax_pmem_core nd_pmem nd_btt
ghash_clmulni_intel aesni_intel aes_x86_64 crypto_simd cryptd glue_helper
input_leds joydev mac_hid nfit serio_raw qemu_fw_cfg sch_fq_codel ip_tables
x_tables autofs4 virtio_net net_failover psmouse failover pata_acpi virtio_blk
i2c_piix4 floppy
[11257.765505] CPU: 6 PID: 5680 Comm: ndctl Not tainted 5.3.0-24-generic
#26-Ubuntu
[11257.765505] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.12.0-1 04/01/2014
[11257.765507] RIP: 0010:add_pages+0x5d/0x70
[11257.765509] Code: 33 c2 01 76 20 48 89 15 99 33 c2 01 48 89 15 a2 33 c2 01
48 c1 e2 0c 48 03 15 97 96 39 01 48 89 15 48 0e c2 01 5b 41 5c 5d c3 <0f> 0b eb
ba 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44
[11257.765509] RSP: 0018:a360c09dfbf0 EFLAGS: 00010282
[11257.765510] RAX: ffea RBX: 0017ffe0 RCX:
[11257.765511] RDX: RSI: 8acb7db17448 RDI:
8acb7db17448
[11257.765512] RBP: a360c09dfc00 R08: 8acb7db17448 R09:
0004
[11257.765512] R10: R11: 0001 R12:
0003fe20
[11257.765513] R13: 0001 R14: a360c09dfc48 R15:
8acb7a7226f8
[11257.765515] FS: 7febc9fd6bc0() GS:8acb7db0()
knlGS:
[11257.765516] CS: 0010 DS: ES: CR0: 80050033
[11257.765517] CR2: 55eec8aab398 CR3: 00013a8fa000 CR4:
000406e0
[11257.765519] Call Trace:
[11257.765523] arch_add_memory+0x41/0x50
[11257.765525] devm_memremap_pages+0x47c/0x640
[11257.765529] pmem_attach_disk+0x173/0x610 [nd_pmem]
[11257.765531] ? devm_memremap+0x67/0xa0
[11257.765532] nd_pmem_probe+0x7f/0xa0 [nd_pmem]
[11257.765542] nvdimm_bus_probe+0x6b/0x170
[11257.765547] really_probe+0xfb/0x3a0
[11257.765549] driver_probe_device+0x5f/0xe0
[11257.765550] device_driver_attach+0x5d/0x70
[11257.765551] bind_store+0xd3/0x110
[11257.765553] drv_attr_store+0x24/0x30
[11257.765554] sysfs_kf_write+0x3e/0x50
[11257.76] kernfs_fop_write+0x11e/0x1a0
[11257.765557] __vfs_write+0x1b/0x40
[11257.765558] vfs_write+0xb9/0x1a0
[11257.765559] ksys_write+0x67/0xe0
[11257.765561] __x64_sys_write+0x1a/0x20
[11257.765567] do_syscall_64+0x5a/0x130
[11257.765693] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[11257.765696] RIP: 0033:0x7febc9e81327
[11257.765698] Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00
f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00
f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
[11257.765698] RSP: 002b:7ffd599433f8 EFLAGS: 0246 ORIG_RAX:
0001
[11257.765699] RAX: ffda RBX: 7febc9fd6ae8 RCX:
7febc9e81327
[11257.765700] RDX: 0007 RSI: 55eec8a9bfa0 RDI:
0004
[11257.765701] RBP: 0004 R08: 0006 R09:
7375622f7379732f
[11257.765701] R10: R11: 0246 R12:
55eec8a9bfa0
[11257.765702] R13: 0001 R14: 0007 R15:
7ffd59943448
[11257.765703] ---[ end trace 442db04e33790cb5 ]---
[11257.782659] nd_pmem: probe of pfn1.0 failed with error -22
It seems that after this point I can't play with my second virtual
nvdimm device (pfn1.0).
A namespace destroy works but a namespace creation does not:
rafaeldtinoco@ndctltest:~$ sudo ndctl list -B
[
{
"provider":"ACPI.NFIT",
"dev":"ndbus0"
}
]
rafaeldtinoco@ndctltest:~$ sudo ndctl list -D
[
{
"dev":"nmem1",
"id":"8680-57341200",
"handle":2,
"phys_id":0
},
{
"dev":"nmem0",
"id":"8680-56341200",
"handle":1,
"phys_id":0
}
]
rafaeldtinoco@ndctltest:~$ sudo ndctl list -R
[
{
"dev":"region1",
"size":1073610752,
"available_size":1073610752,
"max_available_extent":1073610752,
"type":"pmem",
"iset_id":52512795602891997,
"persistence_domain":"unknown"
},
[Kernel-packages] [Bug 1855177] [NEW] qemu nvdimm virtualization + linux 5.3.0-24-generic kernel PROBE ERROR
Public bug reported:
I got a probe error for pfn1.0 (from both pfn0.0 and pfn1.0) when
dealing with ndctl:
[11257.765457] memory add fail, invalid altmap
[11257.765489] WARNING: CPU: 6 PID: 5680 at arch/x86/mm/init_64.c:852
add_pages+0x5d/0x70
[11257.765489] Modules linked in: nls_iso8859_1 edac_mce_amd crct10dif_pclmul
crc32_pclmul dax_pmem_compat device_dax dax_pmem_core nd_pmem nd_btt
ghash_clmulni_intel aesni_intel aes_x86_64 crypto_simd cryptd glue_helper
input_leds joydev mac_hid nfit serio_raw qemu_fw_cfg sch_fq_codel ip_tables
x_tables autofs4 virtio_net net_failover psmouse failover pata_acpi virtio_blk
i2c_piix4 floppy
[11257.765505] CPU: 6 PID: 5680 Comm: ndctl Not tainted 5.3.0-24-generic
#26-Ubuntu
[11257.765505] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.12.0-1 04/01/2014
[11257.765507] RIP: 0010:add_pages+0x5d/0x70
[11257.765509] Code: 33 c2 01 76 20 48 89 15 99 33 c2 01 48 89 15 a2 33 c2 01
48 c1 e2 0c 48 03 15 97 96 39 01 48 89 15 48 0e c2 01 5b 41 5c 5d c3 <0f> 0b eb
ba 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44
[11257.765509] RSP: 0018:a360c09dfbf0 EFLAGS: 00010282
[11257.765510] RAX: ffea RBX: 0017ffe0 RCX:
[11257.765511] RDX: RSI: 8acb7db17448 RDI: 8acb7db17448
[11257.765512] RBP: a360c09dfc00 R08: 8acb7db17448 R09: 0004
[11257.765512] R10: R11: 0001 R12: 0003fe20
[11257.765513] R13: 0001 R14: a360c09dfc48 R15: 8acb7a7226f8
[11257.765515] FS: 7febc9fd6bc0() GS:8acb7db0()
knlGS:
[11257.765516] CS: 0010 DS: ES: CR0: 80050033
[11257.765517] CR2: 55eec8aab398 CR3: 00013a8fa000 CR4: 000406e0
[11257.765519] Call Trace:
[11257.765523] arch_add_memory+0x41/0x50
[11257.765525] devm_memremap_pages+0x47c/0x640
[11257.765529] pmem_attach_disk+0x173/0x610 [nd_pmem]
[11257.765531] ? devm_memremap+0x67/0xa0
[11257.765532] nd_pmem_probe+0x7f/0xa0 [nd_pmem]
[11257.765542] nvdimm_bus_probe+0x6b/0x170
[11257.765547] really_probe+0xfb/0x3a0
[11257.765549] driver_probe_device+0x5f/0xe0
[11257.765550] device_driver_attach+0x5d/0x70
[11257.765551] bind_store+0xd3/0x110
[11257.765553] drv_attr_store+0x24/0x30
[11257.765554] sysfs_kf_write+0x3e/0x50
[11257.76] kernfs_fop_write+0x11e/0x1a0
[11257.765557] __vfs_write+0x1b/0x40
[11257.765558] vfs_write+0xb9/0x1a0
[11257.765559] ksys_write+0x67/0xe0
[11257.765561] __x64_sys_write+0x1a/0x20
[11257.765567] do_syscall_64+0x5a/0x130
[11257.765693] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[11257.765696] RIP: 0033:0x7febc9e81327
[11257.765698] Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00
f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00
f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
[11257.765698] RSP: 002b:7ffd599433f8 EFLAGS: 0246 ORIG_RAX:
0001
[11257.765699] RAX: ffda RBX: 7febc9fd6ae8 RCX: 7febc9e81327
[11257.765700] RDX: 0007 RSI: 55eec8a9bfa0 RDI: 0004
[11257.765701] RBP: 0004 R08: 0006 R09: 7375622f7379732f
[11257.765701] R10: R11: 0246 R12: 55eec8a9bfa0
[11257.765702] R13: 0001 R14: 0007 R15: 7ffd59943448
[11257.765703] ---[ end trace 442db04e33790cb5 ]---
[11257.782659] nd_pmem: probe of pfn1.0 failed with error -22
It seems that after this point I can't play with my second virtual
nvdimm device (pfn1.0).
A namespace destroy works but a namespace creation does not:
rafaeldtinoco@ndctltest:~$ sudo ndctl list -B
[
{
"provider":"ACPI.NFIT",
"dev":"ndbus0"
}
]
rafaeldtinoco@ndctltest:~$ sudo ndctl list -D
[
{
"dev":"nmem1",
"id":"8680-57341200",
"handle":2,
"phys_id":0
},
{
"dev":"nmem0",
"id":"8680-56341200",
"handle":1,
"phys_id":0
}
]
rafaeldtinoco@ndctltest:~$ sudo ndctl list -R
[
{
"dev":"region1",
"size":1073610752,
"available_size":1073610752,
"max_available_extent":1073610752,
"type":"pmem",
"iset_id":52512795602891997,
"persistence_domain":"unknown"
},
{
"dev":"region0",
"size":1073610752,
"available_size":0,
"max_available_extent":0,
"type":"pmem",
"iset_id":52512752653219036,
"persistence_domain":"unknown"
}
]
Now, whenever trying to access namespace1.0 (from region1/nmem1/ndbus) I
get:
[11257.782659] nd_pmem: probe of pfn1.0 failed with error -22
[11332.001388] pfn0.0 initialised, 257024 pages in 8ms
[11332.001818] pmem0: detected capacity change from 0 to 1052770304
[11359.739280] pfn0.1 initialised, 257024 pages in 0ms
[11362.643212] pfn0.0 initialised, 257024 pages in 0ms
[11362.644225] pmem0: detected capacity change from 0 to 1052770304
[11406.230365] pfn0.1 initialised, 257024 pages in 0ms
[11406.231281] pmem0: detected capacity
[Kernel-packages] [Bug 1855177] Re: qemu nvdimm virtualization + linux 5.3.0-24-generic kernel PROBE ERROR
I'm reporting this because I'm not sure yet if its an emulation issue,
since all nvdimm device access I'm doing here is through QEMU emulation
feature, like showed here:
https://raw.githubusercontent.com/rafaeldtinoco/provision/master/kvm/libvirt/nvdimm.xml
or a kernel issue:
rafaeldtinoco@ndctltest:~$ uname -a
Linux ndctltest 5.3.0-24-generic #26-Ubuntu SMP Thu Nov 14 01:33:18 UTC 2019
x86_64 x86_64 x86_64 GNU/Linux
rafaeldtinoco@ndctltest:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu Focal Fossa (development branch)
Release:20.04
Codename: focal
--
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/1855177
Title:
qemu nvdimm virtualization + linux 5.3.0-24-generic kernel PROBE ERROR
Status in linux package in Ubuntu:
Confirmed
Status in qemu package in Ubuntu:
Confirmed
Status in linux source package in Focal:
Confirmed
Status in qemu source package in Focal:
Confirmed
Bug description:
I got a probe error for pfn1.0 (from both pfn0.0 and pfn1.0) when
dealing with ndctl:
[11257.765457] memory add fail, invalid altmap
[11257.765489] WARNING: CPU: 6 PID: 5680 at arch/x86/mm/init_64.c:852
add_pages+0x5d/0x70
[11257.765489] Modules linked in: nls_iso8859_1 edac_mce_amd crct10dif_pclmul
crc32_pclmul dax_pmem_compat device_dax dax_pmem_core nd_pmem nd_btt
ghash_clmulni_intel aesni_intel aes_x86_64 crypto_simd cryptd glue_helper
input_leds joydev mac_hid nfit serio_raw qemu_fw_cfg sch_fq_codel ip_tables
x_tables autofs4 virtio_net net_failover psmouse failover pata_acpi virtio_blk
i2c_piix4 floppy
[11257.765505] CPU: 6 PID: 5680 Comm: ndctl Not tainted 5.3.0-24-generic
#26-Ubuntu
[11257.765505] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.12.0-1 04/01/2014
[11257.765507] RIP: 0010:add_pages+0x5d/0x70
[11257.765509] Code: 33 c2 01 76 20 48 89 15 99 33 c2 01 48 89 15 a2 33 c2 01
48 c1 e2 0c 48 03 15 97 96 39 01 48 89 15 48 0e c2 01 5b 41 5c 5d c3 <0f> 0b eb
ba 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44
[11257.765509] RSP: 0018:a360c09dfbf0 EFLAGS: 00010282
[11257.765510] RAX: ffea RBX: 0017ffe0 RCX:
[11257.765511] RDX: RSI: 8acb7db17448 RDI:
8acb7db17448
[11257.765512] RBP: a360c09dfc00 R08: 8acb7db17448 R09:
0004
[11257.765512] R10: R11: 0001 R12:
0003fe20
[11257.765513] R13: 0001 R14: a360c09dfc48 R15:
8acb7a7226f8
[11257.765515] FS: 7febc9fd6bc0() GS:8acb7db0()
knlGS:
[11257.765516] CS: 0010 DS: ES: CR0: 80050033
[11257.765517] CR2: 55eec8aab398 CR3: 00013a8fa000 CR4:
000406e0
[11257.765519] Call Trace:
[11257.765523] arch_add_memory+0x41/0x50
[11257.765525] devm_memremap_pages+0x47c/0x640
[11257.765529] pmem_attach_disk+0x173/0x610 [nd_pmem]
[11257.765531] ? devm_memremap+0x67/0xa0
[11257.765532] nd_pmem_probe+0x7f/0xa0 [nd_pmem]
[11257.765542] nvdimm_bus_probe+0x6b/0x170
[11257.765547] really_probe+0xfb/0x3a0
[11257.765549] driver_probe_device+0x5f/0xe0
[11257.765550] device_driver_attach+0x5d/0x70
[11257.765551] bind_store+0xd3/0x110
[11257.765553] drv_attr_store+0x24/0x30
[11257.765554] sysfs_kf_write+0x3e/0x50
[11257.76] kernfs_fop_write+0x11e/0x1a0
[11257.765557] __vfs_write+0x1b/0x40
[11257.765558] vfs_write+0xb9/0x1a0
[11257.765559] ksys_write+0x67/0xe0
[11257.765561] __x64_sys_write+0x1a/0x20
[11257.765567] do_syscall_64+0x5a/0x130
[11257.765693] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[11257.765696] RIP: 0033:0x7febc9e81327
[11257.765698] Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00
f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00
f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
[11257.765698] RSP: 002b:7ffd599433f8 EFLAGS: 0246 ORIG_RAX:
0001
[11257.765699] RAX: ffda RBX: 7febc9fd6ae8 RCX:
7febc9e81327
[11257.765700] RDX: 0007 RSI: 55eec8a9bfa0 RDI:
0004
[11257.765701] RBP: 0004 R08: 0006 R09:
7375622f7379732f
[11257.765701] R10: R11: 0246 R12:
55eec8a9bfa0
[11257.765702] R13: 0001 R14: 0007 R15:
7ffd59943448
[11257.765703] ---[ end trace 442db04e33790cb5 ]---
[11257.782659] nd_pmem: probe of pfn1.0 failed with error -22
It seems that after this point I can't play with my second virtual
nvdimm device (pfn1.0).
A namespace destroy works but a namespace creation does not:
rafaeldtinoco@ndctltest:~$ sudo ndctl list -B
[
{
"provider":"ACPI.NFIT",
"dev":"ndbus0"
}
]
[Kernel-packages] [Bug 1811785] Re: NVDIMM-N doesn't work properly on Dell EMC PowerEdge R840
TODOs in this bug:
- End user must confirm the issue is still reproducible and test PPA package
- Mark the case as Confirmed again (instead of Incomplete)
- From that point, the SRU would continue (merge requests already present in
this bug)
- Patches would be sent out to kernel team for inclusion in the next SRU
--
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/1811785
Title:
NVDIMM-N doesn't work properly on Dell EMC PowerEdge R840
Status in ndctl:
Fix Released
Status in linux package in Ubuntu:
Fix Released
Status in ndctl package in Ubuntu:
Fix Released
Status in ndctl source package in Bionic:
Incomplete
Status in ndctl source package in Disco:
Incomplete
Status in ndctl source package in Eoan:
Fix Released
Bug description:
On ubuntu 18.04.1 :
1°) With 4.15.0-43 two default namespaces in raw mode are visible
while there shouldn't be any but no settings change could be applied.
root@server:~# ndctl list -R
[
{
"dev":"region1",
"size":103079215104,
"available_size":0,
"type":"pmem",
"numa_node":1,
"persistence_domain":"unknown"
},
{
"dev":"region0",
"size":103079215104,
"available_size":0,
"type":"pmem",
"numa_node":0,
"persistence_domain":"unknown"
}
]
root@server:~# ndctl list
[
{
"dev":"namespace1.0",
"mode":"raw",
"size":103079215104,
"sector_size":512,
"blockdev":"pmem1",
"numa_node":1
},
{
"dev":"namespace0.0",
"mode":"raw",
"size":103079215104,
"sector_size":512,
"blockdev":"pmem0",
"numa_node":0
}
]
root@server:~# ndctl create-namespace --reconfig=namespace1.0 --type=pmem
--mode=sector -f
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem6: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem6: label area (1024) too small to host
(256 byte) labels
[Kernel-packages] [Bug 1811785] Re: NVDIMM-N doesn't work properly on Dell EMC PowerEdge R840
The kernel issue pointed at the github was solved by:
commit cbaee3aa0e23
Author: Dan Williams
Date: Thu Feb 7 20:56:50 2019
acpi/nfit: Fix bus command validation
BugLink: https://bugs.launchpad.net/bugs/1821607
in kernel: Ubuntu-5.0.0-9.10 (Disco)
AND
commit 3b8d3410b3d8
Author: Dan Williams
Date: Thu Feb 7 20:56:50 2019
acpi/nfit: Fix bus command validation
BugLink: https://bugs.launchpad.net/bugs/1837952
commit ebe9f6f19d80d8978d16078dff3d5bd93ad8d102 upstream.
in kernel: Ubuntu-4.15.0-59.66 (Bionic)
So kernel part is good (or kind of.. actually it is missing 2 fixes
on top of that):
TODO: KERNEL TEAM SHOULD BACKPORT THIS TO BIONIC AND DISCO:
commit ebe9f6f19d80
Author: Dan Williams
Date: Thu Feb 7 20:56:50 2019
acpi/nfit: Fix bus command validation
Fixes: 11189c1089da ("acpi/nfit: Fix command-supported detection")
commit 0171b6b78131
Author: Dan Williams
Date: Sun Feb 3 17:17:27 2019
acpi/nfit: Require opt-in for read-only label configurations
Fixes: 11189c1089da ("acpi/nfit: Fix command-supported detection")
TO FIX THE ISSUE'S FIX
-
TODO: FEEDBACK ABOUT PROPOSED USERLAND FIX
and the userland fix was, indeed, the ndctl patch I did a SRU for.
UNFORTUNATELY I can't reproduce the issue with QEMU. I have tried
different label sizes in multiple attempts and wasn't able to cause the
labeling error (making sure it was fixed). With that it is hard for me
to guarantee the fix is good and I'll depend on a feedback from
reporter.
There is a PPA in comment #19 containing the fix. I'll flag this case as
incomplete while I have no feedback, as we wouldn't be able to verify
the fix in order for it to land -updates archive.
Nevertheless, documentation here might be important to others, in order
to understand the errors.
** Changed in: linux (Ubuntu)
Status: Invalid => Fix Released
** Changed in: ndctl (Ubuntu Bionic)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
** Changed in: ndctl (Ubuntu Disco)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
** Changed in: ndctl (Ubuntu Bionic)
Status: In Progress => Incomplete
** Changed in: ndctl (Ubuntu Disco)
Status: In Progress => Incomplete
--
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/1811785
Title:
NVDIMM-N doesn't work properly on Dell EMC PowerEdge R840
Status in ndctl:
Fix Released
Status in linux package in Ubuntu:
Fix Released
Status in ndctl package in Ubuntu:
Fix Released
Status in ndctl source package in Bionic:
Incomplete
Status in ndctl source package in Disco:
Incomplete
Status in ndctl source package in Eoan:
Fix Released
Bug description:
On ubuntu 18.04.1 :
1°) With 4.15.0-43 two default namespaces in raw mode are visible
while there shouldn't be any but no settings change could be applied.
root@server:~# ndctl list -R
[
{
"dev":"region1",
"size":103079215104,
"available_size":0,
"type":"pmem",
"numa_node":1,
"persistence_domain":"unknown"
},
{
"dev":"region0",
"size":103079215104,
"available_size":0,
"type":"pmem",
"numa_node":0,
"persistence_domain":"unknown"
}
]
root@server:~# ndctl list
[
{
"dev":"namespace1.0",
"mode":"raw",
"size":103079215104,
"sector_size":512,
"blockdev":"pmem1",
"numa_node":1
},
{
"dev":"namespace0.0",
"mode":"raw",
"size":103079215104,
"sector_size":512,
"blockdev":"pmem0",
"numa_node":0
}
]
root@server:~# ndctl create-namespace --reconfig=namespace1.0 --type=pmem
--mode=sector -f
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) label
[Kernel-packages] [Bug 1811785] Re: NVDIMM-N doesn't work properly on Dell EMC PowerEdge R840
Hello Torel and Juliet,
If possible, could you please test the PPA above with either Bionic
and/or Disco and make sure the packages fix the issue ? I'm preparing
bdctl to be in "main" pocket for 20.04:
https://bugs.launchpad.net/ubuntu/+source/ndctl/+bug/1853506
and having this case fix would help to get traction in the MIR (main
inclusion request).
Thank you very much for reporting this and contributing to Ubuntu.
--
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/1811785
Title:
NVDIMM-N doesn't work properly on Dell EMC PowerEdge R840
Status in ndctl:
Fix Released
Status in linux package in Ubuntu:
Invalid
Status in ndctl package in Ubuntu:
Fix Released
Status in ndctl source package in Bionic:
In Progress
Status in ndctl source package in Disco:
In Progress
Status in ndctl source package in Eoan:
Fix Released
Bug description:
On ubuntu 18.04.1 :
1°) With 4.15.0-43 two default namespaces in raw mode are visible
while there shouldn't be any but no settings change could be applied.
root@server:~# ndctl list -R
[
{
"dev":"region1",
"size":103079215104,
"available_size":0,
"type":"pmem",
"numa_node":1,
"persistence_domain":"unknown"
},
{
"dev":"region0",
"size":103079215104,
"available_size":0,
"type":"pmem",
"numa_node":0,
"persistence_domain":"unknown"
}
]
root@server:~# ndctl list
[
{
"dev":"namespace1.0",
"mode":"raw",
"size":103079215104,
"sector_size":512,
"blockdev":"pmem1",
"numa_node":1
},
{
"dev":"namespace0.0",
"mode":"raw",
"size":103079215104,
"sector_size":512,
"blockdev":"pmem0",
"numa_node":0
}
]
root@server:~# ndctl create-namespace --reconfig=namespace1.0 --type=pmem
--mode=sector -f
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem6: label area (1024) too small to host
(256 byte)
[Kernel-packages] [Bug 1811785] Re: NVDIMM-N doesn't work properly on Dell EMC PowerEdge R840
** Changed in: ndctl (Ubuntu Bionic)
Status: Confirmed => In Progress
** Changed in: ndctl (Ubuntu Disco)
Status: Confirmed => 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/1811785
Title:
NVDIMM-N doesn't work properly on Dell EMC PowerEdge R840
Status in ndctl:
Fix Released
Status in linux package in Ubuntu:
Invalid
Status in ndctl package in Ubuntu:
Fix Released
Status in ndctl source package in Bionic:
In Progress
Status in ndctl source package in Disco:
In Progress
Status in ndctl source package in Eoan:
Fix Released
Bug description:
On ubuntu 18.04.1 :
1°) With 4.15.0-43 two default namespaces in raw mode are visible
while there shouldn't be any but no settings change could be applied.
root@server:~# ndctl list -R
[
{
"dev":"region1",
"size":103079215104,
"available_size":0,
"type":"pmem",
"numa_node":1,
"persistence_domain":"unknown"
},
{
"dev":"region0",
"size":103079215104,
"available_size":0,
"type":"pmem",
"numa_node":0,
"persistence_domain":"unknown"
}
]
root@server:~# ndctl list
[
{
"dev":"namespace1.0",
"mode":"raw",
"size":103079215104,
"sector_size":512,
"blockdev":"pmem1",
"numa_node":1
},
{
"dev":"namespace0.0",
"mode":"raw",
"size":103079215104,
"sector_size":512,
"blockdev":"pmem0",
"numa_node":0
}
]
root@server:~# ndctl create-namespace --reconfig=namespace1.0 --type=pmem
--mode=sector -f
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem6: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem6: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem6: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem6: label area (1024) too
[Kernel-packages] [Bug 1811785] Re: NVDIMM-N doesn't work properly on Dell EMC PowerEdge R840
A PPA containing the fixes (Disco and Bionic) will be available here:
https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1811785
--
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/1811785
Title:
NVDIMM-N doesn't work properly on Dell EMC PowerEdge R840
Status in ndctl:
Fix Released
Status in linux package in Ubuntu:
Invalid
Status in ndctl package in Ubuntu:
Fix Released
Status in ndctl source package in Bionic:
Confirmed
Status in ndctl source package in Disco:
Confirmed
Status in ndctl source package in Eoan:
Fix Released
Bug description:
On ubuntu 18.04.1 :
1°) With 4.15.0-43 two default namespaces in raw mode are visible
while there shouldn't be any but no settings change could be applied.
root@server:~# ndctl list -R
[
{
"dev":"region1",
"size":103079215104,
"available_size":0,
"type":"pmem",
"numa_node":1,
"persistence_domain":"unknown"
},
{
"dev":"region0",
"size":103079215104,
"available_size":0,
"type":"pmem",
"numa_node":0,
"persistence_domain":"unknown"
}
]
root@server:~# ndctl list
[
{
"dev":"namespace1.0",
"mode":"raw",
"size":103079215104,
"sector_size":512,
"blockdev":"pmem1",
"numa_node":1
},
{
"dev":"namespace0.0",
"mode":"raw",
"size":103079215104,
"sector_size":512,
"blockdev":"pmem0",
"numa_node":0
}
]
root@server:~# ndctl create-namespace --reconfig=namespace1.0 --type=pmem
--mode=sector -f
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem9: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem6: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem6: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem6: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem6: label area (1024) too small to host
(256 byte)
[Kernel-packages] [Bug 1811785] Re: NVDIMM-N doesn't work properly on Dell EMC PowerEdge R840
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to
host (256 byte) labels
This issue is fixed by:
commit 9c6aae5
Author: Dan Williams
Date: Tue Jan 15 01:51:45 2019
ndctl/init-labels: Fix label slot accounting per UEFI 2.7
Quoting from Linux kernel commit 9e694d9c18dd "libnvdimm, label: change
nvdimm_num_label_slots per UEFI 2.7":
sizeof_namespace_index() fails when NVDIMM devices have the minimum
1024 bytes label storage area. nvdimm_num_label_slots() returns 3
slots while the area is only big enough for 2 slots.
Change nvdimm_num_label_slots() to calculate a number of label slots
according to UEFI 2.7 spec.
Without this fix attempts to initialize labels on a small (1K) label
area results in the following:
libndctl: sizeof_namespace_index: nmem2: label area (1024) too small to
host (128 byte) labels
libndctl: sizeof_namespace_index: nmem2: label area (1024) too small to
host (256 byte) labels
Based on an original patch by Toshi Kani
Fixes: bdaec95463ca ("ndctl: introduce
ndctl_dimm_{validate_labels,init_labels}")
Reported-by: Sujith Pandel
Link: https://github.com/pmem/ndctl/issues/78
Signed-off-by: Dan Williams
Signed-off-by: Vishal Verma
Upstream.
** Changed in: linux (Ubuntu)
Status: Confirmed => Invalid
** Changed in: ndctl (Ubuntu)
Importance: Undecided => Medium
** Changed in: ndctl (Ubuntu)
Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco)
--
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/1811785
Title:
NVDIMM-N doesn't work properly on Dell EMC PowerEdge R840
Status in ndctl:
Fix Released
Status in linux package in Ubuntu:
Invalid
Status in ndctl package in Ubuntu:
Fix Released
Status in ndctl source package in Bionic:
Confirmed
Status in ndctl source package in Disco:
Confirmed
Status in ndctl source package in Eoan:
Fix Released
Bug description:
On ubuntu 18.04.1 :
1°) With 4.15.0-43 two default namespaces in raw mode are visible
while there shouldn't be any but no settings change could be applied.
root@server:~# ndctl list -R
[
{
"dev":"region1",
"size":103079215104,
"available_size":0,
"type":"pmem",
"numa_node":1,
"persistence_domain":"unknown"
},
{
"dev":"region0",
"size":103079215104,
"available_size":0,
"type":"pmem",
"numa_node":0,
"persistence_domain":"unknown"
}
]
root@server:~# ndctl list
[
{
"dev":"namespace1.0",
"mode":"raw",
"size":103079215104,
"sector_size":512,
"blockdev":"pmem1",
"numa_node":1
},
{
"dev":"namespace0.0",
"mode":"raw",
"size":103079215104,
"sector_size":512,
"blockdev":"pmem0",
"numa_node":0
}
]
root@server:~# ndctl create-namespace --reconfig=namespace1.0 --type=pmem
--mode=sector -f
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: n
[Kernel-packages] [Bug 1811785] Re: NVDIMM-N doesn't work properly on Dell EMC PowerEdge R840
It fixes an issue introduced by :
Patch: bdaec95463ca
In version v58
And the fix (9c6aae5) was introduced in v64.
$ rmadison ndctl
ndctl | 61.2-0ubuntu1~18.04.1 | bionic-updates/universe | source, amd64
ndctl | 63-1.3| disco/universe | source, amd64,
arm64, armhf, i386, ppc64el, s390x
ndctl | 65-1 | eoan/universe | source, amd64,
arm64, armhf, i386, ppc64el, s390x
ndctl | 67-1 | focal/universe | source, amd64,
arm64, armhf, i386, ppc64el, s390x
Bionic and Disco are affected.
** Also affects: linux (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: ndctl (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Eoan)
Importance: Undecided
Status: New
** Also affects: ndctl (Ubuntu Eoan)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Disco)
Importance: Undecided
Status: New
** Also affects: ndctl (Ubuntu Disco)
Importance: Undecided
Status: New
** No longer affects: linux (Ubuntu Bionic)
** No longer affects: linux (Ubuntu Disco)
** No longer affects: linux (Ubuntu Eoan)
** Changed in: ndctl (Ubuntu)
Status: Confirmed => Fix Released
** Changed in: ndctl (Ubuntu Eoan)
Status: New => Fix Released
** Changed in: ndctl (Ubuntu Disco)
Status: New => Confirmed
** Changed in: ndctl (Ubuntu Bionic)
Status: New => Confirmed
** Changed in: ndctl (Ubuntu)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
** Changed in: ndctl (Ubuntu Bionic)
Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco)
** Changed in: ndctl (Ubuntu Disco)
Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco)
** Changed in: ndctl (Ubuntu)
Importance: Medium => Undecided
** Changed in: ndctl (Ubuntu Disco)
Importance: Undecided => Medium
** Changed in: ndctl (Ubuntu Bionic)
Importance: Undecided => Medium
--
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/1811785
Title:
NVDIMM-N doesn't work properly on Dell EMC PowerEdge R840
Status in ndctl:
Fix Released
Status in linux package in Ubuntu:
Invalid
Status in ndctl package in Ubuntu:
Fix Released
Status in ndctl source package in Bionic:
Confirmed
Status in ndctl source package in Disco:
Confirmed
Status in ndctl source package in Eoan:
Fix Released
Bug description:
On ubuntu 18.04.1 :
1°) With 4.15.0-43 two default namespaces in raw mode are visible
while there shouldn't be any but no settings change could be applied.
root@server:~# ndctl list -R
[
{
"dev":"region1",
"size":103079215104,
"available_size":0,
"type":"pmem",
"numa_node":1,
"persistence_domain":"unknown"
},
{
"dev":"region0",
"size":103079215104,
"available_size":0,
"type":"pmem",
"numa_node":0,
"persistence_domain":"unknown"
}
]
root@server:~# ndctl list
[
{
"dev":"namespace1.0",
"mode":"raw",
"size":103079215104,
"sector_size":512,
"blockdev":"pmem1",
"numa_node":1
},
{
"dev":"namespace0.0",
"mode":"raw",
"size":103079215104,
"sector_size":512,
"blockdev":"pmem0",
"numa_node":0
}
]
root@server:~# ndctl create-namespace --reconfig=namespace1.0 --type=pmem
--mode=sector -f
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem10: label area (1024) too small to host
(256 byte) labels
libndctl: sizeof_namespace_index: nmem7: label area (1024) too small to host
(256 b
[Kernel-packages] [Bug 1847948] Re: Improve NVMe guest performance on Bionic QEMU
After reading this: * I know, one could as well call that a "feature", but it really is a performance bug fix more than anything else. Also the SRU policy allows exploitation/toleration of new HW especially for LTS releases. Therefore I think this is fine as SRU. I'm okay with that interpretation also. My doubt is about allowing userspace to map the MSI-X table, which is not currently allowed. Actually ... it would be allowed and it would have an "undefined behavior" because of the sparse feature. So, perhaps you're right and it could be seen as a fix both ways: fixing undefined behavior and allowing the MSI-X table to be mmaped, which will allow better performance for QEMU. After re-thinking, I'm +1 on the backport for Bionic Kernel also if others agree. -- 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/1847948 Title: Improve NVMe guest performance on Bionic QEMU Status in The Ubuntu-power-systems project: Triaged Status in linux package in Ubuntu: Fix Released Status in qemu package in Ubuntu: Fix Released Status in linux source package in Bionic: Won't Fix Status in qemu source package in Bionic: Triaged Bug description: [Impact] * In the past qemu has generally not allowd MSI-X BAR mapping on VFIO. But there can be platforms (like ppc64 spapr) that can and want to do exactly that. * Backport two patches from upstream (in since qemu 2.12 / Disco). * Due to that there is a tremendous speedup, especially useful with page size bigger than 4k. This avoids that being split into chunks and makes direct MMIO access possible for the guest. [Test Case] * On ppc64 pass through an NVME device to the guest and run I/O benchmarks, see below for Details how to set that up. Note: this needs the HWE kernel or another kernel fixup for [1]. Note: the test should also be done with the non-HWE kernel, the expectation there is that it would not show the perf benefits, but still work fine [Regression Potential] * Changes: a) if the host driver allows mapping of MSI-X data the entire BAR is mapped. This is only done if the kernel reports that capability [1]. This ensures that only on kernels able to do so qemu does expose the new behavior (safe against regression in that regard) b) on ppc64 MSI-X emulation is disabled for VFIO devices this is local to just this HW and will not affect other HW. Generally the regressions that come to mind are slight changes in behavior (real HW vs the former emulation) that on some weird/old guests could cause trouble. But then it is limited to only PPC where only a small set of certified HW is really allowed. The mapping that might be added even on other platforms should not consume too much extra memory as long as it isn't used. Further since it depends on the kernel capability it isn't randomly issues on kernels where we expect it to fail. So while it is quite a change, it seems safe to me. [Other Info] * I know, one could as well call that a "feature", but it really is a performance bug fix more than anything else. Also the SRU policy allows exploitation/toleration of new HW especially for LTS releases. Therefore I think this is fine as SRU. [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a32295c612c57990d17fb0f41e7134394b2f35f6 == Comment: #0 - Murilo Opsfelder Araujo - 2019-10-11 14:16:14 == ---Problem Description--- Back-port the following patches to Bionic QEMU to improve NVMe guest performance by more than 200%: ?vfio-pci: Allow mmap of MSIX BAR? https://git.qemu.org/?p=qemu.git;a=commit;h=ae0215b2bb56a9d5321a185dde133bfdd306a4c0 ?ppc/spapr, vfio: Turn off MSIX emulation for VFIO devices? https://git.qemu.org/?p=qemu.git;a=commit;h=fcad0d2121976df4b422b4007a5eb7fcaac01134 ---uname output--- na ---Additional Hardware Info--- 0030:01:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller 172Xa/172Xb (rev 01) Machine Type = AC922 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- Install or setup a guest image and boot it. Once guest is running, passthrough the NVMe disk to the guest using the XML: host$ cat nvme-disk.xml host$ virsh attach-device nvme-disk.xml --live On the guest, run fio benchmarks: guest$ fio --direct=1 --rw=randrw --refill_buffers --norandommap --randrepeat=0 --ioengine=libaio --bs=4k --rwmixread=100 --iodepth=16 --runtime=60 --name=job1 --filename=/dev/nvme0n1 --numjobs=4 Results are similar with numjobs=4 and numjobs=64, respectively: READ: bw=385MiB/s (404MB/s), 78.0MiB/s-115MiB/s (81.8MB/s-120MB/s), io=11.3GiB (12.1GB), run=30001-30001msec
[Kernel-packages] [Bug 1847948] Re: Improve NVMe guest performance on Bionic QEMU
Agreed on Frank's last comment. commit a32295c612c57990d17fb0f41e7134394b2f35f6 Author: Alexey Kardashevskiy Date: Wed Dec 13 00:31:31 2017 vfio-pci: Allow mapping MSIX BAR By default VFIO disables mapping of MSIX BAR to the userspace as the userspace may program it in a way allowing spurious interrupts; instead the userspace uses the VFIO_DEVICE_SET_IRQS ioctl. In order to eliminate guessing from the userspace about what is mmapable, VFIO also advertises a sparse list of regions allowed to mmap. This works fine as long as the system page size equals to the MSIX alignment requirement which is 4KB. However with a bigger page size the existing code prohibits mapping non-MSIX parts of a page with MSIX structures so these parts have to be emulated via slow reads/writes on a VFIO device fd. If these emulated bits are accessed often, this has serious impact on performance. This allows mmap of the entire BAR containing MSIX vector table. This removes the sparse capability for PCI devices as it becomes useless. As the userspace needs to know for sure whether mmapping of the MSIX vector containing data can succeed, this adds a new capability - VFIO_REGION_INFO_CAP_MSIX_MAPPABLE - which explicitly tells the userspace that the entire BAR can be mmapped. This does not touch the MSIX mangling in the BAR read/write handlers as we are doing this just to enable direct access to non MSIX registers. Signed-off-by: Alexey Kardashevskiy [aw - fixup whitespace, trim function name] Signed-off-by: Alex Williamson Seems a case for HWE kernels. ** Changed in: linux (Ubuntu Bionic) Status: New => 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/1847948 Title: Improve NVMe guest performance on Bionic QEMU Status in The Ubuntu-power-systems project: Triaged Status in linux package in Ubuntu: Fix Released Status in qemu package in Ubuntu: Fix Released Status in linux source package in Bionic: Won't Fix Status in qemu source package in Bionic: Triaged Bug description: [Impact] * In the past qemu has generally not allowd MSI-X BAR mapping on VFIO. But there can be platforms (like ppc64 spapr) that can and want to do exactly that. * Backport two patches from upstream (in since qemu 2.12 / Disco). * Due to that there is a tremendous speedup, especially useful with page size bigger than 4k. This avoids that being split into chunks and makes direct MMIO access possible for the guest. [Test Case] * On ppc64 pass through an NVME device to the guest and run I/O benchmarks, see below for Details how to set that up. Note: this needs the HWE kernel or another kernel fixup for [1]. Note: the test should also be done with the non-HWE kernel, the expectation there is that it would not show the perf benefits, but still work fine [Regression Potential] * Changes: a) if the host driver allows mapping of MSI-X data the entire BAR is mapped. This is only done if the kernel reports that capability [1]. This ensures that only on kernels able to do so qemu does expose the new behavior (safe against regression in that regard) b) on ppc64 MSI-X emulation is disabled for VFIO devices this is local to just this HW and will not affect other HW. Generally the regressions that come to mind are slight changes in behavior (real HW vs the former emulation) that on some weird/old guests could cause trouble. But then it is limited to only PPC where only a small set of certified HW is really allowed. The mapping that might be added even on other platforms should not consume too much extra memory as long as it isn't used. Further since it depends on the kernel capability it isn't randomly issues on kernels where we expect it to fail. So while it is quite a change, it seems safe to me. [Other Info] * I know, one could as well call that a "feature", but it really is a performance bug fix more than anything else. Also the SRU policy allows exploitation/toleration of new HW especially for LTS releases. Therefore I think this is fine as SRU. [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a32295c612c57990d17fb0f41e7134394b2f35f6 == Comment: #0 - Murilo Opsfelder Araujo - 2019-10-11 14:16:14 == ---Problem Description--- Back-port the following patches to Bionic QEMU to improve NVMe guest performance by more than 200%: ?vfio-pci: Allow mmap of MSIX BAR? https://git.qemu.org/?p=qemu.git;a=commit;h=ae0215b2bb56a9d5321a185dde133bfdd306a4c0 ?ppc/spapr, vfio: Turn off MSIX emulation for VFIO devices?
[Kernel-packages] [Bug 1828495] Re: [KVM][CLX] CPUID_7_0_EDX_ARCH_CAPABILITIES is not enabled in VM.
For the Kernel Support:
---
commit 28c1c9fabf48d6ad596273a11c46e0d0da3e14cd
Author: KarimAllah Ahmed
Date: Thu Feb 1 19:59:44 2018
KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES
Disco: OK - https://bugs.launchpad.net/bugs/1823060
Bionic: OK - https://bugs.launchpad.net/bugs/1838116
-
commit 801e459a6f3a63af9d447e6249088c76ae16efc4
Author: Tom Lendacky
Date: Wed Feb 21 16:39:51 2018
KVM: x86: Add a framework for supporting MSR-based features
Disco: OK
Bionic: OK - since Ubuntu-4.15.0-32.34
-
commit 772439717dbf703b39990be58d8d4e3e4ad0598a
Author: Konrad Rzeszutek Wilk
Date: Wed Apr 25 23:04:22 2018
x86/bugs/intel: Set proper CPU features and setup RDS
Disco: OK
Bionic: OK - since Ubuntu-4.15.0-22.24
-
commit 9f65fb29374ee37856dbad847b4e121aab72b510
Author: Konrad Rzeszutek Wilk
Date: Wed May 9 16:41:38 2018
x86/bugs: Rename _RDS to _SSBD
Disco: OK
Bionic: OK - since Ubuntu-4.15.0-22.24
-
commit 1eaafe91a0df4157521b6417b3dd8430bf5f52f0
Author: Jim Mattson
Date: Wed May 9 18:29:35 2018
kvm: x86: IA32_ARCH_CAPABILITIES is always supported
Disco: OK
Bionic: OK - http://bugs.launchpad.net/bugs/1786352
-
commit cd28325249a1ca0d771557ce823e0308ad629f98
Author: Paolo Bonzini
Date: Mon Jun 25 09:04:37 2018
KVM: VMX: support MSR_IA32_ARCH_CAPABILITIES as a feature MSR
Disco: OK
Bionic: OK - since Ubuntu-4.15.0-32.34
-
commit 0cf9135b773bf32fba9dd8e6699c1b331ee4b749
Author: Sean Christopherson
Date: Thu Mar 7 20:43:02 2019
KVM: x86: Emulate MSR_IA32_ARCH_CAPABILITIES on AMD hosts
Disco: OK - https://bugs.launchpad.net/bugs/1823060
Bionic: OK - https://bugs.launchpad.net/bugs/1838116
-
commit 2bdb76c015df7125783d8394d6339d181cb5bc30
Author: Xiaoyao Li
Date: Fri Mar 8 04:57:20 2019
kvm/x86: Move MSR_IA32_ARCH_CAPABILITIES to array emulated_msrs
Disco: OK - https://bugs.launchpad.net/bugs/1830934
Bionic: Missing - Possibly no need
---
I believe we're all set. I'll have to test in CascadeLake machine to
make though.
** Changed in: linux (Ubuntu Bionic)
Status: Confirmed => Fix Released
** Changed in: linux (Ubuntu Disco)
Status: Confirmed => Fix Released
** Changed in: linux (Ubuntu Eoan)
Status: In Progress => Fix Released
** Changed in: linux (Ubuntu)
Status: In Progress => Fix Released
** Changed in: intel
Status: New => Fix Released
** Changed in: intel
Importance: Undecided => Wishlist
** Changed in: libvirt (Ubuntu Disco)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
** Changed in: linux (Ubuntu)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
** Changed in: linux (Ubuntu Eoan)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
--
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/1828495
Title:
[KVM][CLX] CPUID_7_0_EDX_ARCH_CAPABILITIES is not enabled in VM.
Status in intel:
Fix Released
Status in libvirt package in Ubuntu:
Fix Released
Status in linux package in Ubuntu:
Fix Released
Status in qemu package in Ubuntu:
Fix Released
Status in libvirt source package in Bionic:
Won't Fix
Status in linux source package in Bionic:
Fix Released
Status in qemu source package in Bionic:
Fix Released
Status in libvirt source package in Disco:
Won't Fix
Status in linux source package in Disco:
Fix Released
Status in qemu source package in Disco:
Fix Released
Status in libvirt source package in Eoan:
Fix Released
Status in linux source package in Eoan:
Fix Released
Status in qemu source package in Eoan:
Fix Released
Bug description:
[Impact]
* QEMU does not support IceLake and CascadeLake CPUs specific features.
* Most important feature to be supported is: IA32_ARCH_CAPABILITIES MSR.
* With IA32_ARCH_CAPABILITIES, QEMU is able to advertise HW mitigations:
- Rogue Data Cache Load
- Enhanced IBRS
- RSB Alternate
- L1D flush need on VMENTRY
- speculative Store Bypass
to guests, as described in document:
Intel 336996-Speculative-Execution-Side-Channel-Mitigations.pdf
[Test Case]
* From Original Description:
"""
1. Boot up guest using: -cpu Cascadelake-Server
[root@clx-2s2 yexin]# qemu-system-x86_64 -accel kvm -drive
if=virtio,id=hd,file=/home/x/x,format=qcow2 -m 4096 -smp 4 -cpu
Cascadelake-Server -serial stdio
char device redirected to /dev/pts/3 (label serial0)
qemu-system-x86_64: warning: host doesn't support requested feature:
CPUID.07H:ECX [bit 4]
qemu-system-x86_64: warning: host doesn't support requested feature:
CPUID.07H:ECX [bit 4]
qemu-system-x86_64: warning: host doesn't support requested feature:
CPUID.07H:ECX [bit 4]
qemu-system-x86_64: warning: host doesn't support requested feature:
CPUID.07H:ECX [bit 4]
2. To che
[Kernel-packages] [Bug 1828495] Re: [KVM][CLX] CPUID_7_0_EDX_ARCH_CAPABILITIES is not enabled in VM.
+1 on your summary, looks very good. I will review kernel changes (if they are present or not) and change status accordingly. +1 on the team update. o/ -- 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/1828495 Title: [KVM][CLX] CPUID_7_0_EDX_ARCH_CAPABILITIES is not enabled in VM. Status in intel: New Status in libvirt package in Ubuntu: Fix Released Status in linux package in Ubuntu: In Progress Status in qemu package in Ubuntu: Fix Released Status in libvirt source package in Bionic: Won't Fix Status in linux source package in Bionic: Confirmed Status in qemu source package in Bionic: Fix Released Status in libvirt source package in Disco: Won't Fix Status in linux source package in Disco: Confirmed Status in qemu source package in Disco: Fix Released Status in libvirt source package in Eoan: Fix Released Status in linux source package in Eoan: In Progress Status in qemu source package in Eoan: Fix Released Bug description: [Impact] * QEMU does not support IceLake and CascadeLake CPUs specific features. * Most important feature to be supported is: IA32_ARCH_CAPABILITIES MSR. * With IA32_ARCH_CAPABILITIES, QEMU is able to advertise HW mitigations: - Rogue Data Cache Load - Enhanced IBRS - RSB Alternate - L1D flush need on VMENTRY - speculative Store Bypass to guests, as described in document: Intel 336996-Speculative-Execution-Side-Channel-Mitigations.pdf [Test Case] * From Original Description: """ 1. Boot up guest using: -cpu Cascadelake-Server [root@clx-2s2 yexin]# qemu-system-x86_64 -accel kvm -drive if=virtio,id=hd,file=/home/x/x,format=qcow2 -m 4096 -smp 4 -cpu Cascadelake-Server -serial stdio char device redirected to /dev/pts/3 (label serial0) qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4] qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4] qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4] qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4] 2. To check CPU ID related to features[FEAT_7_0_EDX] ：CPUID_7_0_EDX_ARCH_CAPABILITIES Expected Result: Both host and guest's CPUID.07H EDX bit 29 should be 1. Actual Result: Host's cpuid: 0x0007 0x00: eax=0x ebx=0xd39b ecx=0x0818 edx=0xbc00 (EDX bit 29=1) Guest's cpuid : 0x0007 0x00: eax=0x ebx=0xd19f0fb9 ecx=0x0818 edx=0x8400 (EDX bit 29=0) Commit:2bdb76c015df7125783d8394d6339d181cb5bc30 Target Kerned: 5.1 Target Release: 19.10 """ [Regression Potential] * Most changes are related to CPU type definitions and its supported features. They are all based in upstream changes but, for obvious reasons, backporting and/or cherry-picking those could bring issues. Biggest concern is breaking something that currently works. Right now, the parts being changed that could affect other CPU types would be related to a small refactoring of how the features are organized, and that would be seen right away when trying to start a new VM after the package is installed. * Other tests, related to the features being backported, are being done by our KVM regression tests, including migration combinations, to reduce chances that a regression is introduced. [Other Info] * N/A To manage notifications about this bug go to: https://bugs.launchpad.net/intel/+bug/1828495/+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 1828495] Re: [KVM][CLX] CPUID_7_0_EDX_ARCH_CAPABILITIES is not enabled in VM.
via a CPU model) was disabled by QEMU for some reason. Because this could break migration, snapshots, and save/restore operaions, it's better to just forbid any use of MSR features with QEMU which lacks "unavailable-features" CPU property. Signed-off-by: Jiri Denemark Reviewed-by: Ján Tomko commit 2674d00ed484091faf2b6e6b1efe58ee9a72b96b Author: Jiri Denemark Date: Wed Jun 19 17:22:09 2019 qemu: Drop MSR features from host-model with old QEMU With QEMU versions which lack "unavailable-features" we use CPUID based detection of features which were enabled or disabled once QEMU starts. Thus using MSR features with host-model would result in all of them being marked as disabled in the active domain definition even though QEMU did not actually disable them. Let's make sure we add MSR features to host-model only when "unavailable-features" property is supported by QEMU. Signed-off-by: Jiri Denemark Reviewed-by: Ján Tomko and possibly many others as dependencies to these last. There are some optional things like: commit 5030a7450b0f0117a7903303572c6bda6c012327 Author: Jiri Denemark Date: Fri Jun 7 10:00:28 2019 qemu_command: Use canonical names of CPU features When building QEMU command line, we should use the preferred spelling of each CPU feature without relying on compatibility aliases (which may be removed at some point). The "unavailable-features" CPU property is used as a witness for the correct names of the features in our translation table. Signed-off-by: Jiri Denemark Reviewed-by: Ján Tomko which will change the canonical names for the CPU features (which is something used by the commits that will create the arch_capabilities and unavailable-features features). So, IMO, we should keep QEMU cmdline XML arguments for the mitigation features and tell users to use *at least* Eoan's libvirt for the arch- capabilities feature in libvirt. Orelse we would have to either backport tons of libvirt patches OR workaround this by creating or own version, which is a no-no for SRUs. Any objection ? PS: We still need to document the arch-capabilities and all the mitigations it advertises (and features enabled/disabled in cmdline amd, possibly, now, in libvirt as cmdline xml extra arguments). ** Changed in: libvirt (Ubuntu Disco) Status: Confirmed => Opinion ** Changed in: libvirt (Ubuntu Bionic) Status: Confirmed => Won't Fix ** Changed in: libvirt (Ubuntu Bionic) Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned) ** Changed in: linux (Ubuntu Disco) Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned) ** Changed in: linux (Ubuntu Bionic) Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned) -- 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/1828495 Title: [KVM][CLX] CPUID_7_0_EDX_ARCH_CAPABILITIES is not enabled in VM. Status in intel: New Status in libvirt package in Ubuntu: Fix Released Status in linux package in Ubuntu: In Progress Status in qemu package in Ubuntu: Fix Released Status in libvirt source package in Bionic: Won't Fix Status in linux source package in Bionic: Confirmed Status in qemu source package in Bionic: Fix Released Status in libvirt source package in Disco: Opinion Status in linux source package in Disco: Confirmed Status in qemu source package in Disco: Fix Released Status in libvirt source package in Eoan: Fix Released Status in linux source package in Eoan: In Progress Status in qemu source package in Eoan: Fix Released Bug description: [Impact] * QEMU does not support IceLake and CascadeLake CPUs specific features. * Most important feature to be supported is: IA32_ARCH_CAPABILITIES MSR. * With IA32_ARCH_CAPABILITIES, QEMU is able to advertise HW mitigations: - Rogue Data Cache Load - Enhanced IBRS - RSB Alternate - L1D flush need on VMENTRY - speculative Store Bypass to guests, as described in document: Intel 336996-Speculative-Execution-Side-Channel-Mitigations.pdf [Test Case] * From Original Description: """ 1. Boot up guest using: -cpu Cascadelake-Server [root@clx-2s2 yexin]# qemu-system-x86_64 -accel kvm -drive if=virtio,id=hd,file=/home/x/x,format=qcow2 -m 4096 -smp 4 -cpu Cascadelake-Server -serial stdio char device redirected to /dev/pts/3 (label serial0) qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4] qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4] qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4] qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [
[Kernel-packages] [Bug 1846237] Re: Kernel Panic while virsh dump of Guest with 300G RAM is triggered.
Manoj, This is a soft lockup in schedule() - a task is waiting I/O completion - inside a KVM guest. The guest kernel has a completion that will be awaken, re-scheduling the task back to a CPU run queue, as soon as the I/O is finished (the I/O usually contains a handle that, as soon as I/O is confirmed to be sent by transport layer, calls a callback function to "release" the completion and let the application to be re-scheduled. Depending on how the cache is configured, this logic MIGHT also check for I/O being committed in I/O server, only allowing the task to continue its logic after that: That is also considered as a soft lockup (tasks keeps re- scheduling itself until the I/o is done). The guest has just panic'ed because it had "panic on hung" configured. It is highly probable that the "issue" here is I/O contention causing the lockup inside the Guest, nothing else. There isn't any I/O timeouts - because bad transport and/or block device layer - or any other hard lockup due to a dead lock, for example. So, unless something else, undocumented in this bug, is happening, there is not much to be done without more information. To help kernel team, it would be good for IBM to provide more information on what was being done on the HOST, how the I/O devices are configured in KVM guest, etc. Thats my 5 cents. -- 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/1846237 Title: Kernel Panic while virsh dump of Guest with 300G RAM is triggered. Status in The Ubuntu-power-systems project: Triaged Status in libvirt package in Ubuntu: Invalid Status in linux package in Ubuntu: New Bug description: == Comment: #0 - HARIHARAN T. SUNDARESH REDDY - 2019-04-01 12:23:14 == ---Problem Description--- Kernel panic occurred when `virsh dump` is triggered on the guest with 300G of RAM. ---uname output--- Linux ltcgen6 4.15.0-1017.19-bz175922-ibm-gt #bz175922 SMP Thu Mar 21 09:34:09 CDT 2019 ppc64le ppc64le ppc64le GNU/Linux ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1. Define guest with 300G RAM, Start the guest 2. Run the following command `virsh dump ubuntui_hsr /home/vm.core --memory-only --live' 3. Wait for some time, kernel panic will be see in the console. --Log--- [ 1692.657251] INFO: task journal-offline:7763 blocked for more than 120 seconds. [ 1692.657251] INFO: task journal-offline:7763 blocked for more than 120 seconds. [ 1692.657754] Not tainted 4.15.0-1017.19-bz175922-ibm-gt #bz175922 [ 1692.657754] Not tainted 4.15.0-1017.19-bz175922-ibm-gt #bz175922 [ 1692.658220] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1692.658220] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1692.658839] Kernel panic - not syncing: hung_task: blocked tasks [ 1692.658839] Kernel panic - not syncing: hung_task: blocked tasks [ 1692.659238] CPU: 48 PID: 785 Comm: khungtaskd Not tainted 4.15.0-1017.19-bz175922-ibm-gt #bz175922 [ 1692.659238] CPU: 48 PID: 785 Comm: khungtaskd Not tainted 4.15.0-1017.19-bz175922-ibm-gt #bz175922 [ 1692.659835] Call Trace: [ 1692.659835] Call Trace: [ 1692.660025] [c08fd0eefbf8] [c0cea13c] dump_stack+0xb0/0xf4 (unreliable) [ 1692.660025] [c08fd0eefbf8] [c0cea13c] dump_stack+0xb0/0xf4 (unreliable) [ 1692.660564] [c08fd0eefc38] [c0110020] panic+0x148/0x328 [ 1692.660564] [c08fd0eefc38] [c0110020] panic+0x148/0x328 [ 1692.661004] [c08fd0eefcd8] [c0233a08] watchdog+0x2c8/0x420 [ 1692.661004] [c08fd0eefcd8] [c0233a08] watchdog+0x2c8/0x420 [ 1692.661429] [c08fd0eefdb8] [c0140068] kthread+0x1a8/0x1b0 [ 1692.661429] [c08fd0eefdb8] [c0140068] kthread+0x1a8/0x1b0 [ 1692.661881] [c08fd0eefe28] [c000b654] ret_from_kernel_thread+0x5c/0x88 [ 1692.661881] [c08fd0eefe28] [c000b654] ret_from_kernel_thread+0x5c/0x88 [ 1692.662439] Sending IPI to other CPUs [ 1692.662439] Sending IPI to other CPUs [ 1693.971250] IPI complete [ 1693.971250] IPI complete [ 1694.122536] kexec: Starting switchover sequence. [ 1694.122536] kexec: Starting switchover sequence. [ 1827.285354188,3] PHB#0003[0:3]: CRESET: Unexpected slot state 0102, resetting... [ 1831.426449832,3] PHB#0030[8:0]: CRESET: Unexpected slot state 0102, resetting... [ 1832.158844758,3] PHB#0033[8:3]: CRESET: Unexpected slot state 0102, resetting... [ 1832.403055326,3] PHB#0034[8:4]: CRESET: Unexpected slot state 0102, resetting... [1.924644]
[Kernel-packages] [Bug 1788098] Re: Avoid migration issues with aligned 2MB THB
** Changed in: linux (Ubuntu Disco) Importance: Undecided => Medium -- 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/1788098 Title: Avoid migration issues with aligned 2MB THB Status in The Ubuntu-power-systems project: Invalid Status in linux package in Ubuntu: Fix Released Status in qemu package in Ubuntu: Invalid Status in linux source package in Bionic: Won't Fix Status in linux source package in Cosmic: Invalid Status in linux source package in Disco: Fix Released Status in linux source package in Eoan: Fix Released Status in qemu source package in Eoan: Invalid Bug description: FYI: This blocks bug 1781526 - once this one here is resolved we can go on with SRU considerations for 1781526 --- Comment From jhop...@us.ibm.com 2018-08-20 17:12 EDT--- Hi, in some environments it was observed that this qemu patch to enable THP made it more likely to hit guest migration issues, however the following kernel patch resolves those migration issues: https://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git/commit/?h=kvm-ppc-next=c066fafc595eef5ae3c83ae3a8305956b8c3ef15 KVM: PPC: Book3S HV: Use correct pagesize in kvm_unmap_radix() Once merged upstream, it would be good to include that change as well to avoid potential migration problems. Should I open a new bug for that or is it better to track here? Note Paelzer: I have not seen related migration issues myself, but it seems reasonable and confirmed by IBM. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1788098/+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 1788098] Re: Avoid migration issues with aligned 2MB THB
Frank, based on your previous comment I'm also flagging disco as Fix Released. Please fix this if it makes no sense (just to be accurate). Thx! ** Also affects: qemu (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Disco) Importance: Undecided Status: New ** No longer affects: qemu (Ubuntu Disco) -- 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/1788098 Title: Avoid migration issues with aligned 2MB THB Status in The Ubuntu-power-systems project: Invalid Status in linux package in Ubuntu: Fix Released Status in qemu package in Ubuntu: Invalid Status in linux source package in Bionic: Won't Fix Status in linux source package in Cosmic: Invalid Status in linux source package in Disco: New Status in linux source package in Eoan: Fix Released Status in qemu source package in Eoan: Invalid Bug description: FYI: This blocks bug 1781526 - once this one here is resolved we can go on with SRU considerations for 1781526 --- Comment From jhop...@us.ibm.com 2018-08-20 17:12 EDT--- Hi, in some environments it was observed that this qemu patch to enable THP made it more likely to hit guest migration issues, however the following kernel patch resolves those migration issues: https://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git/commit/?h=kvm-ppc-next=c066fafc595eef5ae3c83ae3a8305956b8c3ef15 KVM: PPC: Book3S HV: Use correct pagesize in kvm_unmap_radix() Once merged upstream, it would be good to include that change as well to avoid potential migration problems. Should I open a new bug for that or is it better to track here? Note Paelzer: I have not seen related migration issues myself, but it seems reasonable and confirmed by IBM. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1788098/+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 1771222] Re: Using sysctl to permanently disable IPv6 doesn't have any effect
*** This bug is a duplicate of bug 50093 *** https://bugs.launchpad.net/bugs/50093 ** This bug has been marked a duplicate of bug 50093 Some sysctls are ignored on boot -- 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/1771222 Title: Using sysctl to permanently disable IPv6 doesn't have any effect Status in linux package in Ubuntu: Confirmed Bug description: Shows up in version 18.04 of Ubuntu. I added the following 2 lines in /etc/sysctl.d/99-sysctl.conf and /etc/sysctl.d/01-disable-ipv6.conf: ``` net.ipv6.conf.all.disable_ipv6=1 net.ipv6.conf.default.disable_ipv6=1 ``` Rebooting my machine sets those parameters for "all" and "default" but not for the sysctl options of my network interface: ``` net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 net.ipv6.conf.ens160.disable_ipv6 = 0 ``` I use disable_ipv6 above as an example. I've also verified this with the promote_secondaries option of ipv4. I can always restart systemd-sysctl.service at every boot and this will set net.ipv6.conf.ens160.disable_ipv6 to 1. Unfortunately though this won't work for devices that are hot-plugged. Other info: - version signature: Ubuntu 4.15.0-20.21-generic 4.15.17 - lspci is attached To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1771222/+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 1834522] Re: Bionic QEMU with Bionic Kernel hangs in AMD FX-8350 with cpu-host as passthrough
** Tags removed: verification-needed-bionic ** Tags added: verification-done verification-done-bionic -- 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/1834522 Title: Bionic QEMU with Bionic Kernel hangs in AMD FX-8350 with cpu-host as passthrough Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Committed Bug description: [Impact] * Nested AMD KVM guest does not work in AMD CPUs when using host-passthrough as cpu-mode. * QEMU does not start, hanging before the VM initialization. [Test Case] * Bionic KVM GUEST tries to use nested KVM in AMD CPU * to use the following XML file: https://paste.ubuntu.com/p/BSyFY7ksR5/ * to have AMD FX(tm)-8350 Eight-Core Processor CPU or similar * to use Xenial qemu on top of a HWE kernel -> works [Regression Potential] * KVM SVM could be affected but patch is from upstream, fixes the specific issue and has been tested by me in my currently developing workstation (heavy usage). [Other Info] * Patches have been sent to kernel team mailing list. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1834522/+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 1834522] Re: Bionic QEMU with Bionic Kernel hangs in AMD FX-8350 with cpu-host as passthrough
It solves the problem and I'm sorry for taking so long to verify... Commit: Author: Sean Christopherson Date: Thu Aug 29 14:06:58 2019 KVM: x86: SVM: Set EMULTYPE_NO_REEXECUTE for RSM emulation BugLink: https://bugs.launchpad.net/bugs/1834522 Indeed solves the problem. 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/1834522 Title: Bionic QEMU with Bionic Kernel hangs in AMD FX-8350 with cpu-host as passthrough Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Committed Bug description: [Impact] * Nested AMD KVM guest does not work in AMD CPUs when using host-passthrough as cpu-mode. * QEMU does not start, hanging before the VM initialization. [Test Case] * Bionic KVM GUEST tries to use nested KVM in AMD CPU * to use the following XML file: https://paste.ubuntu.com/p/BSyFY7ksR5/ * to have AMD FX(tm)-8350 Eight-Core Processor CPU or similar * to use Xenial qemu on top of a HWE kernel -> works [Regression Potential] * KVM SVM could be affected but patch is from upstream, fixes the specific issue and has been tested by me in my currently developing workstation (heavy usage). [Other Info] * Patches have been sent to kernel team mailing list. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1834522/+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 1834522] Re: Bionic QEMU with Bionic Kernel hangs in AMD FX-8350 with cpu-host as passthrough
Waiting kernel team sponsorship. Thx. -- 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/1834522 Title: Bionic QEMU with Bionic Kernel hangs in AMD FX-8350 with cpu-host as passthrough Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: In Progress Bug description: [Impact] * Nested AMD KVM guest does not work in AMD CPUs when using host-passthrough as cpu-mode. * QEMU does not start, hanging before the VM initialization. [Test Case] * Bionic KVM GUEST tries to use nested KVM in AMD CPU * to use the following XML file: https://paste.ubuntu.com/p/BSyFY7ksR5/ * to have AMD FX(tm)-8350 Eight-Core Processor CPU or similar * to use Xenial qemu on top of a HWE kernel -> works [Regression Potential] * KVM SVM could be affected but patch is from upstream, fixes the specific issue and has been tested by me in my currently developing workstation (heavy usage). [Other Info] * Patches have been sent to kernel team mailing list. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1834522/+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 1834522] Re: Bionic QEMU with Bionic Kernel hangs in AMD FX-8350 with cpu-host as passthrough
Sent out to kernel team: https://lists.ubuntu.com/archives/kernel-team/2019-August/103470.html https://lists.ubuntu.com/archives/kernel-team/2019-August/103471.html ** Description changed: [Impact] - * QEMU does not work in some AMD hardware when using host-passthrough as cpu-mode (usually to allow nested KVM to work). - * QEMU does not start, hanging before the VM initialization. + * Nested AMD KVM guest does not work in AMD CPUs when using host-passthrough as cpu-mode. + * QEMU does not start, hanging before the VM initialization. [Test Case] - * to use Xenial qemu on top of a regular Xenial kernel -> doesn't work (intermittent) - * to use the following XML file: https://paste.ubuntu.com/p/BSyFY7ksR5/ - * to have AMD FX(tm)-8350 Eight-Core Processor CPU or similar - * to use Xenial qemu on top of a HWE kernel -> works + * Bionic KVM GUEST tries to use nested KVM in AMD CPU + * to use the following XML file: https://paste.ubuntu.com/p/BSyFY7ksR5/ + * to have AMD FX(tm)-8350 Eight-Core Processor CPU or similar + * to use Xenial qemu on top of a HWE kernel -> works [Regression Potential] - * TODO + * KVM SVM could be affected but patch is from upstream, fixes the + specific issue and has been tested by me in my currently developing + workstation (heavy usage). [Other Info] - * TODO + * Patches have been sent to 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/1834522 Title: Bionic QEMU with Bionic Kernel hangs in AMD FX-8350 with cpu-host as passthrough Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: In Progress Bug description: [Impact] * Nested AMD KVM guest does not work in AMD CPUs when using host-passthrough as cpu-mode. * QEMU does not start, hanging before the VM initialization. [Test Case] * Bionic KVM GUEST tries to use nested KVM in AMD CPU * to use the following XML file: https://paste.ubuntu.com/p/BSyFY7ksR5/ * to have AMD FX(tm)-8350 Eight-Core Processor CPU or similar * to use Xenial qemu on top of a HWE kernel -> works [Regression Potential] * KVM SVM could be affected but patch is from upstream, fixes the specific issue and has been tested by me in my currently developing workstation (heavy usage). [Other Info] * Patches have been sent to kernel team mailing list. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1834522/+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 1834522] Re: Bionic QEMU with Bionic Kernel hangs in AMD FX-8350 with cpu-host as passthrough
Also needed:
commit 35be0aded76b54a24dc8aa678a71bca22273e8d8
Author: Sean Christopherson
Date: Thu Aug 23 17:56:47 2018
KVM: x86: SVM: Set EMULTYPE_NO_REEXECUTE for RSM emulation
Re-execution after an emulation decode failure is only intended to
handle a case where two or vCPUs race to write a shadowed page, i.e.
we should never re-execute an instruction as part of RSM emulation.
Add a new helper, kvm_emulate_instruction_from_buffer(), to support
emulating from a pre-defined buffer. This eliminates the last direct
call to x86_emulate_instruction() outside of kvm_mmu_page_fault(),
which means x86_emulate_instruction() can be unexported in a future
patch.
Fixes: 7607b7174405 ("KVM: SVM: install RSM intercept")
Cc: Brijesh Singh
Signed-off-by: Sean Christopherson
Cc: sta...@vger.kernel.org
Signed-off-by: Radim Krčmář
--
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/1834522
Title:
Bionic QEMU with Bionic Kernel hangs in AMD FX-8350 with cpu-host as
passthrough
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Bionic:
In Progress
Bug description:
[Impact]
* QEMU does not work in some AMD hardware when using host-passthrough as
cpu-mode (usually to allow nested KVM to work).
* QEMU does not start, hanging before the VM initialization.
[Test Case]
* to use Xenial qemu on top of a regular Xenial kernel -> doesn't work
(intermittent)
* to use the following XML file: https://paste.ubuntu.com/p/BSyFY7ksR5/
* to have AMD FX(tm)-8350 Eight-Core Processor CPU or similar
* to use Xenial qemu on top of a HWE kernel -> works
[Regression Potential]
* TODO
[Other Info]
* TODO
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1834522/+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 1834522] Re: Bionic QEMU with Bionic Kernel hangs in AMD FX-8350 with cpu-host as passthrough
I've included patch above into Bionic tree: commit 9bff5f095923aab04411cf4e9135b975b70e3ead (tag: Ubuntu-4.15.0-58.64, origin/master, origin/HEAD) Author: Stefan Bader Date: Tue Aug 6 10:45:37 2019 UBUNTU: Ubuntu-4.15.0-58.64 And it, indeed, fixed 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/1834522 Title: Bionic QEMU with Bionic Kernel hangs in AMD FX-8350 with cpu-host as passthrough Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: In Progress Bug description: [Impact] * QEMU does not work in some AMD hardware when using host-passthrough as cpu-mode (usually to allow nested KVM to work). * QEMU does not start, hanging before the VM initialization. [Test Case] * to use Xenial qemu on top of a regular Xenial kernel -> doesn't work (intermittent) * to use the following XML file: https://paste.ubuntu.com/p/BSyFY7ksR5/ * to have AMD FX(tm)-8350 Eight-Core Processor CPU or similar * to use Xenial qemu on top of a HWE kernel -> works [Regression Potential] * TODO [Other Info] * TODO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1834522/+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 1834522] Re: Bionic QEMU with Bionic Kernel hangs in AMD FX-8350 with cpu-host as passthrough
** Changed in: linux (Ubuntu Bionic) Status: Confirmed => 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/1834522 Title: Bionic QEMU with Bionic Kernel hangs in AMD FX-8350 with cpu-host as passthrough Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: In Progress Bug description: [Impact] * QEMU does not work in some AMD hardware when using host-passthrough as cpu-mode (usually to allow nested KVM to work). * QEMU does not start, hanging before the VM initialization. [Test Case] * to use Xenial qemu on top of a regular Xenial kernel -> doesn't work (intermittent) * to use the following XML file: https://paste.ubuntu.com/p/BSyFY7ksR5/ * to have AMD FX(tm)-8350 Eight-Core Processor CPU or similar * to use Xenial qemu on top of a HWE kernel -> works [Regression Potential] * TODO [Other Info] * TODO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1834522/+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 1834522] Re: Bionic QEMU with Bionic Kernel hangs in AMD FX-8350 with cpu-host as passthrough
# BISECT LOG git bisect start # bad: [0adb32858b0bddf4ada5f364a84ed60b196dbcda] Linux 4.16 git bisect bad 0adb32858b0bddf4ada5f364a84ed60b196dbcda # good: [d8a5b80568a9cb66810e75b182018e9edb68e8ff] Linux 4.15 git bisect good d8a5b80568a9cb66810e75b182018e9edb68e8ff # good: [c14376de3a1befa70d9811ca2872d47367b48767] printk: Wake klogd when passing console_lock owner git bisect good c14376de3a1befa70d9811ca2872d47367b48767 # good: [2246edfaf88dc368e8671b04afd54412625df60a] Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma git bisect good 2246edfaf88dc368e8671b04afd54412625df60a # good: [dfe8db22372873d205c78a9fd5370b1b088a2b87] Merge tag 'drm-misc-fixes-2018-02-21' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes git bisect good dfe8db22372873d205c78a9fd5370b1b088a2b87 # bad: [4665c6b04651e96c1e2eb9129a30d6055040ff73] Merge tag 'linux-can-fixes-for-4.16-20180312' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can git bisect bad 4665c6b04651e96c1e2eb9129a30d6055040ff73 # bad: [3499de32fa6b608ba646380ac3838d30a2558ead] Merge tag 'linux-kselftest-4.16-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest git bisect bad 3499de32fa6b608ba646380ac3838d30a2558ead # good: [65738c6b461a8bb0b056e024299738f7cc9a28b7] Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux git bisect good 65738c6b461a8bb0b056e024299738f7cc9a28b7 # good: [c23a75759191e84f4ba15b85ea4f97bd544b5362] Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect good c23a75759191e84f4ba15b85ea4f97bd544b5362 # bad: [d4858aaf6bd8a90e2dacc0dfec2077e334dcedbf] Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm git bisect bad d4858aaf6bd8a90e2dacc0dfec2077e334dcedbf # good: [0eb578009a1d530a11846d7c4733a5db04730884] tools/kvm_stat: use a more pythonic way to iterate over dictionaries git bisect good 0eb578009a1d530a11846d7c4733a5db04730884 # good: [fe2a3027e74e40a3ece3a4c1e4e51403090a907a] KVM: x86: fix backward migration with async_PF git bisect good fe2a3027e74e40a3ece3a4c1e4e51403090a907a # bad: [7607b7174405aec7441ff6c970833c463114040a] KVM: SVM: install RSM intercept git bisect bad 7607b7174405aec7441ff6c970833c463114040a # good: [e5699f56bc91a286f006b0728085e0b4e8f5749b] crypto: ccp: Fix sparse, use plain integer as NULL pointer git bisect good e5699f56bc91a286f006b0728085e0b4e8f5749b # good: [3e233385ef4a217a2812115ed84d4be36eb16817] KVM: SVM: no need to call access_ok() in LAUNCH_MEASURE command git bisect good 3e233385ef4a217a2812115ed84d4be36eb16817 # first bad commit: [7607b7174405aec7441ff6c970833c463114040a] KVM: SVM: install RSM intercept # NOTE I was doing "invert" bisection.. so the bad commit is actually what seems to have fixed the issue: commit 7607b7174405aec7441ff6c970833c463114040a Author: Brijesh Singh Date: Mon Feb 19 10:14:44 2018 -0600 KVM: SVM: install RSM intercept RSM instruction is used by the SMM handler to return from SMM mode. Currently, rsm causes a #UD - which results in instruction fetch, decode, and emulate. By installing the RSM intercept we can avoid the instruction fetch since we know that #VMEXIT was due to rsm. The patch is required for the SEV guest, because in case of SEV guest memory is encrypted with guest-specific key and hypervisor will not able to fetch the instruction bytes from the guest memory. Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Joerg Roedel Cc: Borislav Petkov Cc: Tom Lendacky Signed-off-by: Brijesh Singh Signed-off-by: Paolo Bonzini -- 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/1834522 Title: Bionic QEMU with Bionic Kernel hangs in AMD FX-8350 with cpu-host as passthrough Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: In Progress Bug description: [Impact] * QEMU does not work in some AMD hardware when using host-passthrough as cpu-mode (usually to allow nested KVM to work). * QEMU does not start, hanging before the VM initialization. [Test Case] * to use Xenial qemu on top of a regular Xenial kernel -> doesn't work (intermittent) * to use the following XML file: https://paste.ubuntu.com/p/BSyFY7ksR5/ * to have AMD FX(tm)-8350 Eight-Core Processor CPU or similar * to use Xenial qemu on top of a HWE kernel -> works [Regression Potential] * TODO [Other Info] * TODO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1834522/+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 1828495] Re: [KVM][CLX] CPUID_7_0_EDX_ARCH_CAPABILITIES is not enabled in VM.
** Changed in: libvirt (Ubuntu Disco) Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco) ** Changed in: libvirt (Ubuntu Bionic) Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco) ** Changed in: qemu (Ubuntu Disco) Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned) ** Changed in: qemu (Ubuntu Bionic) Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned) ** Changed in: linux (Ubuntu Bionic) Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco) ** Changed in: linux (Ubuntu Disco) Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco) ** Changed in: linux (Ubuntu Eoan) Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco) -- 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/1828495 Title: [KVM][CLX] CPUID_7_0_EDX_ARCH_CAPABILITIES is not enabled in VM. Status in intel: New Status in libvirt package in Ubuntu: Fix Released Status in linux package in Ubuntu: In Progress Status in qemu package in Ubuntu: Fix Released Status in libvirt source package in Bionic: Confirmed Status in linux source package in Bionic: Confirmed Status in qemu source package in Bionic: Fix Released Status in libvirt source package in Disco: Confirmed Status in linux source package in Disco: Confirmed Status in qemu source package in Disco: Fix Released Status in libvirt source package in Eoan: Fix Released Status in linux source package in Eoan: In Progress Status in qemu source package in Eoan: Fix Released Bug description: [Impact] * QEMU does not support IceLake and CascadeLake CPUs specific features. * Most important feature to be supported is: IA32_ARCH_CAPABILITIES MSR. * With IA32_ARCH_CAPABILITIES, QEMU is able to advertise HW mitigations: - Rogue Data Cache Load - Enhanced IBRS - RSB Alternate - L1D flush need on VMENTRY - speculative Store Bypass to guests, as described in document: Intel 336996-Speculative-Execution-Side-Channel-Mitigations.pdf [Test Case] * From Original Description: """ 1. Boot up guest using: -cpu Cascadelake-Server [root@clx-2s2 yexin]# qemu-system-x86_64 -accel kvm -drive if=virtio,id=hd,file=/home/x/x,format=qcow2 -m 4096 -smp 4 -cpu Cascadelake-Server -serial stdio char device redirected to /dev/pts/3 (label serial0) qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4] qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4] qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4] qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4] 2. To check CPU ID related to features[FEAT_7_0_EDX] ：CPUID_7_0_EDX_ARCH_CAPABILITIES Expected Result: Both host and guest's CPUID.07H EDX bit 29 should be 1. Actual Result: Host's cpuid: 0x0007 0x00: eax=0x ebx=0xd39b ecx=0x0818 edx=0xbc00 (EDX bit 29=1) Guest's cpuid : 0x0007 0x00: eax=0x ebx=0xd19f0fb9 ecx=0x0818 edx=0x8400 (EDX bit 29=0) Commit:2bdb76c015df7125783d8394d6339d181cb5bc30 Target Kerned: 5.1 Target Release: 19.10 """ [Regression Potential] * Most changes are related to CPU type definitions and its supported features. They are all based in upstream changes but, for obvious reasons, backporting and/or cherry-picking those could bring issues. Biggest concern is breaking something that currently works. Right now, the parts being changed that could affect other CPU types would be related to a small refactoring of how the features are organized, and that would be seen right away when trying to start a new VM after the package is installed. * Other tests, related to the features being backported, are being done by our KVM regression tests, including migration combinations, to reduce chances that a regression is introduced. [Other Info] * N/A To manage notifications about this bug go to: https://bugs.launchpad.net/intel/+bug/1828495/+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 1840847] Re: cpuinfo_linux_get_max_processors_count always warns Ubuntu default MAX cpu values (stderr)
** Description changed: From bug: https://bugs.launchpad.net/bugs/1840511 - clockhouse builds test started failing because of the presence of stderr + clickhouse builds test started failing because of the presence of stderr whenever using the function: cpuinfo_linux_get_max_processors_count(void) From cpuid library. This happens because: #if defined(__ANDROID__) && !defined(CPU_SETSIZE) /* * Android NDK headers before platform 21 do not define CPU_SETSIZE, * so we hard-code its value, as defined in platform 21 headers */ #if defined(__LP64__) static const uint32_t default_max_processors_count = 1024; #else static const uint32_t default_max_processors_count = 32; #endif #else static const uint32_t default_max_processors_count = CPU_SETSIZE; #endif #if !defined(__ANDROID__) /* * sched.h is only used for CPU_SETSIZE constant. * Android NDK headers before platform 21 do have this constant in sched.h */ #include #endif and resolving includes: x86_64-linux-gnu/bits/cpu-set.h: /* Size definition for CPU sets. */ #define __CPU_SETSIZE 1024 And the warning: Warning in cpuinfo: kernel_max value of 8191 parsed from /sys/devices/system/cpu/kernel_max exceeds platform-default limit 1023 Will always be displayed in Ubuntu OS, when it should NOT (does not make any sense to trigger a warning for something that can't be changed). FOR THE KERNEL TEAM: Should ubuntu update sched.h and/or cpu-set.h to reflect its decision in using 8192 max CPUs ? -- 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/1840847 Title: cpuinfo_linux_get_max_processors_count always warns Ubuntu default MAX cpu values (stderr) Status in cpuinfo package in Ubuntu: In Progress Status in linux package in Ubuntu: Confirmed Bug description: From bug: https://bugs.launchpad.net/bugs/1840511 clickhouse builds test started failing because of the presence of stderr whenever using the function: cpuinfo_linux_get_max_processors_count(void) From cpuid library. This happens because: #if defined(__ANDROID__) && !defined(CPU_SETSIZE) /* * Android NDK headers before platform 21 do not define CPU_SETSIZE, * so we hard-code its value, as defined in platform 21 headers */ #if defined(__LP64__) static const uint32_t default_max_processors_count = 1024; #else static const uint32_t default_max_processors_count = 32; #endif #else static const uint32_t default_max_processors_count = CPU_SETSIZE; #endif #if !defined(__ANDROID__) /* * sched.h is only used for CPU_SETSIZE constant. * Android NDK headers before platform 21 do have this constant in sched.h */ #include #endif and resolving includes: x86_64-linux-gnu/bits/cpu-set.h: /* Size definition for CPU sets. */ #define __CPU_SETSIZE 1024 And the warning: Warning in cpuinfo: kernel_max value of 8191 parsed from /sys/devices/system/cpu/kernel_max exceeds platform-default limit 1023 Will always be displayed in Ubuntu OS, when it should NOT (does not make any sense to trigger a warning for something that can't be changed). FOR THE KERNEL TEAM: Should ubuntu update sched.h and/or cpu-set.h to reflect its decision in using 8192 max CPUs ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cpuinfo/+bug/1840847/+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 1840847] Re: cpuinfo_linux_get_max_processors_count always warns Ubuntu default MAX cpu values (stderr)
PPA containing clickhouse build (LP: #1840511) and cpuinfo with this fix: https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1840511 Debdiff with proposed changes are attached to 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/1840847 Title: cpuinfo_linux_get_max_processors_count always warns Ubuntu default MAX cpu values (stderr) Status in cpuinfo package in Ubuntu: In Progress Status in linux package in Ubuntu: Confirmed Bug description: From bug: https://bugs.launchpad.net/bugs/1840511 clockhouse builds test started failing because of the presence of stderr whenever using the function: cpuinfo_linux_get_max_processors_count(void) From cpuid library. This happens because: #if defined(__ANDROID__) && !defined(CPU_SETSIZE) /* * Android NDK headers before platform 21 do not define CPU_SETSIZE, * so we hard-code its value, as defined in platform 21 headers */ #if defined(__LP64__) static const uint32_t default_max_processors_count = 1024; #else static const uint32_t default_max_processors_count = 32; #endif #else static const uint32_t default_max_processors_count = CPU_SETSIZE; #endif #if !defined(__ANDROID__) /* * sched.h is only used for CPU_SETSIZE constant. * Android NDK headers before platform 21 do have this constant in sched.h */ #include #endif and resolving includes: x86_64-linux-gnu/bits/cpu-set.h: /* Size definition for CPU sets. */ #define __CPU_SETSIZE 1024 And the warning: Warning in cpuinfo: kernel_max value of 8191 parsed from /sys/devices/system/cpu/kernel_max exceeds platform-default limit 1023 Will always be displayed in Ubuntu OS, when it should NOT (does not make any sense to trigger a warning for something that can't be changed). FOR THE KERNEL TEAM: Should ubuntu update sched.h and/or cpu-set.h to reflect its decision in using 8192 max CPUs ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cpuinfo/+bug/1840847/+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 1840847] Re: cpuinfo_linux_get_max_processors_count always warns Ubuntu default MAX cpu values (stderr)
** Patch added: "cpuinfo_0.0~git20190201.d5e37ad-1ubuntu1.debdiff" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1840847/+attachment/5283577/+files/cpuinfo_0.0~git20190201.d5e37ad-1ubuntu1.debdiff ** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed ** Changed in: linux (Ubuntu) Importance: Undecided => Low ** Description changed: From bug: https://bugs.launchpad.net/bugs/1840511 clockhouse builds test started failing because of the presence of stderr whenever using the function: cpuinfo_linux_get_max_processors_count(void) From cpuid library. This happens because: #if defined(__ANDROID__) && !defined(CPU_SETSIZE) /* * Android NDK headers before platform 21 do not define CPU_SETSIZE, * so we hard-code its value, as defined in platform 21 headers */ #if defined(__LP64__) static const uint32_t default_max_processors_count = 1024; #else static const uint32_t default_max_processors_count = 32; #endif #else static const uint32_t default_max_processors_count = CPU_SETSIZE; #endif #if !defined(__ANDROID__) /* * sched.h is only used for CPU_SETSIZE constant. * Android NDK headers before platform 21 do have this constant in sched.h */ #include #endif and resolving includes: x86_64-linux-gnu/bits/cpu-set.h: /* Size definition for CPU sets. */ #define __CPU_SETSIZE 1024 And the warning: Warning in cpuinfo: kernel_max value of 8191 parsed from /sys/devices/system/cpu/kernel_max exceeds platform-default limit 1023 Will always be displayed in Ubuntu OS, when it should NOT (does not make any sense to trigger a warning for something that can't be changed). + FOR THE KERNEL TEAM: + Should ubuntu update sched.h and/or cpu-set.h to reflect its decision in using 8192 max CPUs ? -- 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/1840847 Title: cpuinfo_linux_get_max_processors_count always warns Ubuntu default MAX cpu values (stderr) Status in cpuinfo package in Ubuntu: In Progress Status in linux package in Ubuntu: Confirmed Bug description: From bug: https://bugs.launchpad.net/bugs/1840511 clockhouse builds test started failing because of the presence of stderr whenever using the function: cpuinfo_linux_get_max_processors_count(void) From cpuid library. This happens because: #if defined(__ANDROID__) && !defined(CPU_SETSIZE) /* * Android NDK headers before platform 21 do not define CPU_SETSIZE, * so we hard-code its value, as defined in platform 21 headers */ #if defined(__LP64__) static const uint32_t default_max_processors_count = 1024; #else static const uint32_t default_max_processors_count = 32; #endif #else static const uint32_t default_max_processors_count = CPU_SETSIZE; #endif #if !defined(__ANDROID__) /* * sched.h is only used for CPU_SETSIZE constant. * Android NDK headers before platform 21 do have this constant in sched.h */ #include #endif and resolving includes: x86_64-linux-gnu/bits/cpu-set.h: /* Size definition for CPU sets. */ #define __CPU_SETSIZE 1024 And the warning: Warning in cpuinfo: kernel_max value of 8191 parsed from /sys/devices/system/cpu/kernel_max exceeds platform-default limit 1023 Will always be displayed in Ubuntu OS, when it should NOT (does not make any sense to trigger a warning for something that can't be changed). FOR THE KERNEL TEAM: Should ubuntu update sched.h and/or cpu-set.h to reflect its decision in using 8192 max CPUs ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cpuinfo/+bug/1840847/+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 1840847] Re: cpuinfo_linux_get_max_processors_count always warns Ubuntu default MAX cpu values (stderr)
I'm changing CPUINFO_LOG_LEVEL from warning to error only to mitigate this issue. Unfortunately this is the best way to address: https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1840511 Right now, allowing clickhouse build to succeed and unblocking MySQL 8 upgrade. ** Changed in: cpuinfo (Ubuntu) Status: New => In Progress ** Changed in: cpuinfo (Ubuntu) Importance: Undecided => Medium ** Changed in: cpuinfo (Ubuntu) Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco) -- 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/1840847 Title: cpuinfo_linux_get_max_processors_count always warns Ubuntu default MAX cpu values (stderr) Status in cpuinfo package in Ubuntu: In Progress Status in linux package in Ubuntu: Incomplete Bug description: From bug: https://bugs.launchpad.net/bugs/1840511 clockhouse builds test started failing because of the presence of stderr whenever using the function: cpuinfo_linux_get_max_processors_count(void) From cpuid library. This happens because: #if defined(__ANDROID__) && !defined(CPU_SETSIZE) /* * Android NDK headers before platform 21 do not define CPU_SETSIZE, * so we hard-code its value, as defined in platform 21 headers */ #if defined(__LP64__) static const uint32_t default_max_processors_count = 1024; #else static const uint32_t default_max_processors_count = 32; #endif #else static const uint32_t default_max_processors_count = CPU_SETSIZE; #endif #if !defined(__ANDROID__) /* * sched.h is only used for CPU_SETSIZE constant. * Android NDK headers before platform 21 do have this constant in sched.h */ #include #endif and resolving includes: x86_64-linux-gnu/bits/cpu-set.h: /* Size definition for CPU sets. */ #define __CPU_SETSIZE 1024 And the warning: Warning in cpuinfo: kernel_max value of 8191 parsed from /sys/devices/system/cpu/kernel_max exceeds platform-default limit 1023 Will always be displayed in Ubuntu OS, when it should NOT (does not make any sense to trigger a warning for something that can't be changed). Should ubuntu update sched.h and/or cpu-set.h to reflect its decision in using 8192 max CPUs ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cpuinfo/+bug/1840847/+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 1840847] [NEW] cpuinfo_linux_get_max_processors_count always warns Ubuntu default MAX cpu values (stderr)
Public bug reported: >From bug: https://bugs.launchpad.net/bugs/1840511 clockhouse builds test started failing because of the presence of stderr whenever using the function: cpuinfo_linux_get_max_processors_count(void) >From cpuid library. This happens because: #if defined(__ANDROID__) && !defined(CPU_SETSIZE) /* * Android NDK headers before platform 21 do not define CPU_SETSIZE, * so we hard-code its value, as defined in platform 21 headers */ #if defined(__LP64__) static const uint32_t default_max_processors_count = 1024; #else static const uint32_t default_max_processors_count = 32; #endif #else static const uint32_t default_max_processors_count = CPU_SETSIZE; #endif #if !defined(__ANDROID__) /* * sched.h is only used for CPU_SETSIZE constant. * Android NDK headers before platform 21 do have this constant in sched.h */ #include #endif and resolving includes: x86_64-linux-gnu/bits/cpu-set.h: /* Size definition for CPU sets. */ #define __CPU_SETSIZE 1024 And the warning: Warning in cpuinfo: kernel_max value of 8191 parsed from /sys/devices/system/cpu/kernel_max exceeds platform-default limit 1023 Will always be displayed in Ubuntu OS, when it should NOT (does not make any sense to trigger a warning for something that can't be changed). Should ubuntu update sched.h and/or cpu-set.h to reflect its decision in using 8192 max CPUs ? ** Affects: cpuinfo (Ubuntu) Importance: Undecided Status: New ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete ** Also affects: linux (Ubuntu) Importance: Undecided Status: New ** Description changed: From bug: https://bugs.launchpad.net/bugs/1840511 - clockhouse test started failing because of the presence of stderr + clockhouse builds test started failing because of the presence of stderr whenever using the function: cpuinfo_linux_get_max_processors_count(void) From cpuid library. This happens because: #if defined(__ANDROID__) && !defined(CPU_SETSIZE) - /* - * Android NDK headers before platform 21 do not define CPU_SETSIZE, - * so we hard-code its value, as defined in platform 21 headers - */ - #if defined(__LP64__) - static const uint32_t default_max_processors_count = 1024; - #else - static const uint32_t default_max_processors_count = 32; - #endif + /* + * Android NDK headers before platform 21 do not define CPU_SETSIZE, + * so we hard-code its value, as defined in platform 21 headers + */ + #if defined(__LP64__) + static const uint32_t default_max_processors_count = 1024; + #else + static const uint32_t default_max_processors_count = 32; + #endif #else - static const uint32_t default_max_processors_count = CPU_SETSIZE; + static const uint32_t default_max_processors_count = CPU_SETSIZE; #endif #if !defined(__ANDROID__) - /* - * sched.h is only used for CPU_SETSIZE constant. - * Android NDK headers before platform 21 do have this constant in sched.h - */ - #include + /* + * sched.h is only used for CPU_SETSIZE constant. + * Android NDK headers before platform 21 do have this constant in sched.h + */ + #include #endif and resolving includes: x86_64-linux-gnu/bits/cpu-set.h: /* Size definition for CPU sets. */ #define __CPU_SETSIZE 1024 And the warning: Warning in cpuinfo: kernel_max value of 8191 parsed from /sys/devices/system/cpu/kernel_max exceeds platform-default limit 1023 Will always be displayed in Ubuntu OS, when it should NOT (does not make any sense to trigger a warning for something that can't be changed). Should ubuntu update sched.h and/or cpu-set.h to reflect its decision in using 8192 max CPUs ? -- 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/1840847 Title: cpuinfo_linux_get_max_processors_count always warns Ubuntu default MAX cpu values (stderr) Status in cpuinfo package in Ubuntu: New Status in linux package in Ubuntu: Incomplete Bug description: From bug: https://bugs.launchpad.net/bugs/1840511 clockhouse builds test started failing because of the presence of stderr whenever using the function: cpuinfo_linux_get_max_processors_count(void) From cpuid library. This happens because: #if defined(__ANDROID__) && !defined(CPU_SETSIZE) /* * Android NDK headers before platform 21 do not define CPU_SETSIZE, * so we hard-code its value, as defined in platform 21 headers */ #if defined(__LP64__) static const uint32_t default_max_processors_count = 1024; #else static const uint32_t default_max_processors_count = 32;
[Kernel-packages] [Bug 1828495] Re: [KVM][CLX] CPUID_7_0_EDX_ARCH_CAPABILITIES is not enabled in VM.
Definitely! Will provide feedback soon! -- 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/1828495 Title: [KVM][CLX] CPUID_7_0_EDX_ARCH_CAPABILITIES is not enabled in VM. Status in intel: New Status in libvirt package in Ubuntu: In Progress Status in linux package in Ubuntu: In Progress Status in qemu package in Ubuntu: Fix Released Status in libvirt source package in Bionic: Confirmed Status in linux source package in Bionic: Confirmed Status in qemu source package in Bionic: Fix Released Status in libvirt source package in Disco: Confirmed Status in linux source package in Disco: Confirmed Status in qemu source package in Disco: Fix Released Status in libvirt source package in Eoan: In Progress Status in linux source package in Eoan: In Progress Status in qemu source package in Eoan: Fix Released Bug description: [Impact] * QEMU does not support IceLake and CascadeLake CPUs specific features. * Most important feature to be supported is: IA32_ARCH_CAPABILITIES MSR. * With IA32_ARCH_CAPABILITIES, QEMU is able to advertise HW mitigations: - Rogue Data Cache Load - Enhanced IBRS - RSB Alternate - L1D flush need on VMENTRY - speculative Store Bypass to guests, as described in document: Intel 336996-Speculative-Execution-Side-Channel-Mitigations.pdf [Test Case] * From Original Description: """ 1. Boot up guest using: -cpu Cascadelake-Server [root@clx-2s2 yexin]# qemu-system-x86_64 -accel kvm -drive if=virtio,id=hd,file=/home/x/x,format=qcow2 -m 4096 -smp 4 -cpu Cascadelake-Server -serial stdio char device redirected to /dev/pts/3 (label serial0) qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4] qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4] qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4] qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4] 2. To check CPU ID related to features[FEAT_7_0_EDX] ：CPUID_7_0_EDX_ARCH_CAPABILITIES Expected Result: Both host and guest's CPUID.07H EDX bit 29 should be 1. Actual Result: Host's cpuid: 0x0007 0x00: eax=0x ebx=0xd39b ecx=0x0818 edx=0xbc00 (EDX bit 29=1) Guest's cpuid : 0x0007 0x00: eax=0x ebx=0xd19f0fb9 ecx=0x0818 edx=0x8400 (EDX bit 29=0) Commit:2bdb76c015df7125783d8394d6339d181cb5bc30 Target Kerned: 5.1 Target Release: 19.10 """ [Regression Potential] * Most changes are related to CPU type definitions and its supported features. They are all based in upstream changes but, for obvious reasons, backporting and/or cherry-picking those could bring issues. Biggest concern is breaking something that currently works. Right now, the parts being changed that could affect other CPU types would be related to a small refactoring of how the features are organized, and that would be seen right away when trying to start a new VM after the package is installed. * Other tests, related to the features being backported, are being done by our KVM regression tests, including migration combinations, to reduce chances that a regression is introduced. [Other Info] * N/A To manage notifications about this bug go to: https://bugs.launchpad.net/intel/+bug/1828495/+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 1496942] Re: Infiniband (mellanox) SR-IOV and libvirt + libnl problems
This bug was related to incompatibilities between dkms provided by the Mellanox OFED - implementing some new netlink protocol addons - and Ubuntu kernel. This type of issues have already been addressed between Canonical and Mellanox (but might occur again while Mellanox OFED is using for RDMA and IB related setups). ** Changed in: linux (Ubuntu) Status: Triaged => Incomplete -- 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/1496942 Title: Infiniband (mellanox) SR-IOV and libvirt + libnl problems Status in linux package in Ubuntu: Incomplete Status in linux package in Debian: New Bug description: When trying to start an IB SR-IOV guest by using the following XML: following the Mellanox SR-IOV guide, we are able to start guests using kernel 3.16 (Utopic). We are NOT able to start guests using 3.13 OR 3.19. The following error occurs: 2015-09-17 02:25:07.208+: 52157: info : libvirt version: 1.2.12, package: 1.2.12-0ubuntu14.1~cloud0 2015-09-17 02:25:07.208+: 52157: error : virSecurityDriverLookup:80 : unsupported configuration: Security driver apparmor not enabled 2015-09-17 02:25:42.308+: 52281: info : libvirt version: 1.2.12, package: 1.2.12-0ubuntu14.1~cloud0 2015-09-17 02:25:42.308+: 52281: error : virSecurityDriverLookup:80 : unsupported configuration: Security driver apparmor not enabled 2015-09-17 02:25:48.996+: 52274: error : virNetDevParseVfConfig:1905 : internal error: missing IFLA_VF_INFO in netlink response 2015-09-17 02:25:49.006+: 52274: error : virFileReadAll:1347 : Failed to open file '/var/run/libvirt/hostdevmgr/ib0_vf0': No such file or directory 2015-09-17 02:25:49.006+: 52274: error : virFileReadAll:1347 : Failed to open file '/var/run/libvirt/qemu/ib0_vf0': No such file or directory So probably there is some regression in between 3.16 and 3.19 for the IFLA_VF_INFO feature from netlink AND this has to be backported to kernel 3.13 for Trusty to have IB SR-IOV working. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1496942/+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 1828495] Re: [KVM][CLX] CPUID_7_0_EDX_ARCH_CAPABILITIES is not enabled in VM.
>From the MR: https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/qemu/+git/qemu/+merge/368804/+index? I'm testing now the Bionic version in -proposed: 7.17 Containing the missing MDS-NO arch-capabilities flag. Running the following command: $ sudo /usr/bin/qemu-system-x86_64 -name guest="guest" -machine accel=kvm -cpu host,+arch-capabilities,+ssbd,+md-clear,+rdctl-no,+ibrs- all,+skip-l1dfl-vmentry,+mds-no -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 7e55c71a-558f-412c-8445-db0e95fc549f -display none -no-user-config -nodefaults -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -kernel /var/lib/libvirt/images/guest/vmlinuz -initrd /var/lib/libvirt/images/guest/initrd.img -append "root=/dev/vda noresume console=tty0 console=ttyS0,38400n8 apparmor=0 net.ifnames=0 crashkernel=256M" -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/guest/disk01.ext4.qcow2,format=qcow2,if=none,id =drive-virtio-disk0 -device virtio-blk- pci,scsi=off,bus=pci.0,addr=0x3,drive=drive-virtio-disk0,id=virtio- disk0,bootindex=1 -device virtio-balloon- pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on -serial stdio This is the cpu_flags: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single ssbd ibrs ibpb ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpxavx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves arat umip pku ospke avx512_vnni md_clear arch_capabilities bugs: spectre_v1 spectre_v2 spec_store_bypass And reading MSR directly: $ sudo rdmsr 0x10a 2b We also have bits in place: 0 1 3 5, meaning it is good for all announced mitigations. Note: Running the same command with Cascadelake-Server as cpu has the same results. -- Running Cascadelake-Server CPU without setting any CPU flags: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 arat pku ospke avx512_vnni arch_capabilities bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds $ sudo rdmsr 0x10a 0 Expected as we are not enabling the mitigations by default. -- With all the tests I'm setting disco -proposed package: 2.11+dfsg- 1ubuntu7.17 as verified. ** Tags removed: verification-needed verification-needed-bionic ** Tags added: verification-done verification-done-bionic -- 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/1828495 Title: [KVM][CLX] CPUID_7_0_EDX_ARCH_CAPABILITIES is not enabled in VM. Status in intel: New Status in libvirt package in Ubuntu: Fix Released Status in linux package in Ubuntu: In Progress Status in qemu package in Ubuntu: Fix Released Status in libvirt source package in Bionic: Confirmed Status in linux source package in Bionic: Confirmed Status in qemu source package in Bionic: Fix Committed Status in libvirt source package in Cosmic: Won't Fix Status in linux source package in Cosmic: Won't Fix Status in qemu source package in Cosmic: Won't Fix Status in libvirt source package in Disco: Confirmed Status in linux source package in Disco: Confirmed Status in qemu source package in Disco: Fix Committed Status in libvirt source package in Eoan: Fix Released Status in linux source package in Eoan: In Progress Status in qemu source package in Eoan: Fix Released Bug description: [Impact] * QEMU does not support IceLake and CascadeLake CPUs specific features. * Most important feature to be supported is: IA32_ARCH_CAPABILITIES MSR. * With IA32_ARCH_CAPABILITIES, QEMU is able to advertise HW mitigations: - Rogue Data Cache Load - Enhanced IBRS - RSB Alternate - L1D flush need on VMENTRY - speculative Store Bypass to guests, as described in document: Intel 336996-Speculative-Execution-Side-Channel-Mitigations.pdf [Test Case]
[Kernel-packages] [Bug 1828495] Re: [KVM][CLX] CPUID_7_0_EDX_ARCH_CAPABILITIES is not enabled in VM.
I'll wait for the next SRU for bionic to be in -proposed to provide Bionic full verification just like I did to Disco. It shall not take too long and the version currently in -proposed will be superseded by the one we have in the merge request right now. -- 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/1828495 Title: [KVM][CLX] CPUID_7_0_EDX_ARCH_CAPABILITIES is not enabled in VM. Status in intel: New Status in libvirt package in Ubuntu: Fix Released Status in linux package in Ubuntu: In Progress Status in qemu package in Ubuntu: Fix Released Status in libvirt source package in Bionic: Confirmed Status in linux source package in Bionic: Confirmed Status in qemu source package in Bionic: Fix Committed Status in libvirt source package in Cosmic: Won't Fix Status in linux source package in Cosmic: Won't Fix Status in qemu source package in Cosmic: Won't Fix Status in libvirt source package in Disco: Confirmed Status in linux source package in Disco: Confirmed Status in qemu source package in Disco: Fix Committed Status in libvirt source package in Eoan: Fix Released Status in linux source package in Eoan: In Progress Status in qemu source package in Eoan: Fix Released Bug description: [Impact] * QEMU does not support IceLake and CascadeLake CPUs specific features. * Most important feature to be supported is: IA32_ARCH_CAPABILITIES MSR. * With IA32_ARCH_CAPABILITIES, QEMU is able to advertise HW mitigations: - Rogue Data Cache Load - Enhanced IBRS - RSB Alternate - L1D flush need on VMENTRY - speculative Store Bypass to guests, as described in document: Intel 336996-Speculative-Execution-Side-Channel-Mitigations.pdf [Test Case] * From Original Description: """ 1. Boot up guest using: -cpu Cascadelake-Server [root@clx-2s2 yexin]# qemu-system-x86_64 -accel kvm -drive if=virtio,id=hd,file=/home/x/x,format=qcow2 -m 4096 -smp 4 -cpu Cascadelake-Server -serial stdio char device redirected to /dev/pts/3 (label serial0) qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4] qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4] qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4] qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4] 2. To check CPU ID related to features[FEAT_7_0_EDX] ：CPUID_7_0_EDX_ARCH_CAPABILITIES Expected Result: Both host and guest's CPUID.07H EDX bit 29 should be 1. Actual Result: Host's cpuid: 0x0007 0x00: eax=0x ebx=0xd39b ecx=0x0818 edx=0xbc00 (EDX bit 29=1) Guest's cpuid : 0x0007 0x00: eax=0x ebx=0xd19f0fb9 ecx=0x0818 edx=0x8400 (EDX bit 29=0) Commit:2bdb76c015df7125783d8394d6339d181cb5bc30 Target Kerned: 5.1 Target Release: 19.10 """ [Regression Potential] * Most changes are related to CPU type definitions and its supported features. They are all based in upstream changes but, for obvious reasons, backporting and/or cherry-picking those could bring issues. Biggest concern is breaking something that currently works. Right now, the parts being changed that could affect other CPU types would be related to a small refactoring of how the features are organized, and that would be seen right away when trying to start a new VM after the package is installed. * Other tests, related to the features being backported, are being done by our KVM regression tests, including migration combinations, to reduce chances that a regression is introduced. [Other Info] * N/A To manage notifications about this bug go to: https://bugs.launchpad.net/intel/+bug/1828495/+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 1828495] Re: [KVM][CLX] CPUID_7_0_EDX_ARCH_CAPABILITIES is not enabled in VM.
# Disco verification: ubuntu@disco:~$ sudo /usr/bin/qemu-system-x86_64 -name guest="guest" -machine accel=kvm -cpu host,+arch-capabilities,+ssbd,+md-clear,+rdctl- no,+ibrs-all,+skip-l1dfl-vmentry,+mds-no -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 7e55c71a-558f- 412c-8445-db0e95fc549f -display none -no-user-config -nodefaults -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no- shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -kernel /var/lib/libvirt/images/guest/vmlinuz -initrd /var/lib/libvirt/images/guest/initrd.img -append "root=/dev/vda noresume console=tty0 console=ttyS0,38400n8 apparmor=0 net.ifnames=0 crashkernel=256M" -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/guest/disk01.ext4.qcow2,format=qcow2,if=none,id =drive-virtio-disk0 -device virtio-blk- pci,scsi=off,bus=pci.0,addr=0x3,drive=drive-virtio-disk0,id=virtio- disk0,bootindex=1 -device virtio-balloon- pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on -serial stdio -> changing "host" to CascadeLake-Server also works the same way. Provided me: inaddy@guest:~$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 85 model name : Intel(R) Xeon(R) Gold 6252 CPU @ 2.10GHz stepping: 6 microcode : 0x1 cpu MHz : 2095.076 cache size : 16384 KB physical id : 0 siblings: 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single ssbd ibrs ibpb ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves arat umip pku ospke avx512_vnni md_clear arch_capabilities bugs: spectre_v1 spectre_v2 spec_store_bypass bogomips: 4190.15 clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: AND reading the MSR directly: inaddy@guest:~$ sudo rdmsr 0x10a 2b We have bits: 0 1 3 and 5 like it should be. - Running same QEMU cmd line, enabling +arch-capabilities in CascadeLake- Server but without specifying any other CPU flags: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 arat pku ospke avx512_vnni arch_capabilities bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds inaddy@guest:~$ sudo rdmsr 0x10a 0 We are not enabling any mitigation flag in arch-capabilities MSR by default, like we planned so. All CPU capabilities are going to be enabled by hand and/or through libvirt XML definitions as soon as libvirt gets the capabilities (this same bug). - Marking Disco as verified. Thank you! ** Tags removed: verification-needed-disco ** Tags added: verification-done-disco -- 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/1828495 Title: [KVM][CLX] CPUID_7_0_EDX_ARCH_CAPABILITIES is not enabled in VM. Status in intel: New Status in libvirt package in Ubuntu: Fix Released Status in linux package in Ubuntu: In Progress Status in qemu package in Ubuntu: Fix Released Status in libvirt source package in Bionic: Confirmed Status in linux source package in Bionic: Confirmed Status in qemu source package in Bionic: Fix Committed Status in libvirt source package in Cosmic: Won't Fix Status in linux source package in Cosmic: Won't Fix Status in qemu source package in Cosmic: Won't Fix Status in libvirt source package in Disco: Confirmed Status in linux source package in Disco: Confirmed Status in qemu source package in Disco: Fix Committed Status in libvirt source package in Eoan: Fix Released Status in linux source package in Eoan: In Progress Status in qemu source package in Eoan: Fix Released Bug
