** Changed in: linux (Ubuntu Bionic)
Status: Incomplete => Invalid
** Changed in: linux (Ubuntu Focal)
Status: Incomplete => In Progress
** Changed in: linux (Ubuntu Impish)
Status: Incomplete => In Progress
** Changed in: linux (Ubuntu Jammy)
Status: Incomplete => In Progress
** Changed in: linux (Ubuntu Focal)
Assignee: (unassigned) => Jeff Lane (bladernr)
** Changed in: linux (Ubuntu Impish)
Assignee: (unassigned) => Jeff Lane (bladernr)
** Changed in: linux (Ubuntu Jammy)
Assignee: (unassigned) => Jeff Lane (bladernr)
** Changed in: linux (Ubuntu Jammy)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu Impish)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu Focal)
Importance: Undecided => Medium
** Description changed:
+ [Impact]
+
+ A hardware partner discovered they were unable to install Ubuntu on some
+ servers using VROC setups. They point to this issue involving DMAR that
+ is blocking discovery of the VROC RAID devices:
+
+
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2565e5b69c44b4e42469afea3cc5a97e74d1ed45
+
+ `git bisect` points to this offending commit ee81ee84f873 ("PCI:
+ vmd: Disable MSI-X remapping when possible"), which disables VMD MSI
+ remapping. The IOMMU hardware blocks the compatibility format
+ interrupt request because Interrupt Remapping Enable Status (IRES) and
+ Extended Interrupt Mode Enable (EIME) are enabled. Please refer to
+ section "5.1.4 Interrupt-Remapping Hardware Operation" in Intel VT-d
+ spec.
+
+ To fix the issue, VMD driver still enables the interrupt remapping
+ irrespective of VMD_FEAT_CAN_BYPASS_MSI_REMAP if the IOMMU subsystem
+ enables the interrupt remapping.
+
+ [Fix]
+
+ 2565e5b69c44 PCI: vmd: Do not disable MSI-X remapping if interrupt
+ remapping is enabled by IOMMU
+
+ [Test Plan]
+
+ 1. Boot into VRoC controller in uEFI Setup and create a raid10 disk.
+ 2. Install affected Ubuntu release on the RAID10.
+ 3. The system hangs at "Partitions formatting 33%".
+
+ [Where problems could occur]
+
+ The fix itself is a very small change to drivers/pci/controller/vmd.c
+ and problems should not occur, the patch has been tested and accepted
+ upstream as of 5.16.
+
+ That said, I doubt this will fix 18.04.6 as it would require a respin to
+ get the patched kernel onto the ISO. 20.04 should pick it up in ISO in
+ 20.04.5, so there could still be the initial issue since those ISOs
+ would be lacking the patched kernel.
+
+ [Other Info]
+
+ As noted, this would need to not only land in the kernel but land in the
+ kernel in the ISO to resolve the issue in the installation process.
+ I'll bring this back as far as Focal with the expectation that while
+ 20.04.4 is too late, it will be present using the GA kernel in 20.04.5
+ later on.
+
+
+ *************************************************************************
+
+
+ Original Bug Summary:
+
A hardware partner has been testing 18.04 subiquity images on their
servers with VROC enabled and configured in a RAID 10 setup.
-
In their own words:
Steps to reproduce:
- 1. Boot into VRoC controller in uEFI Setup and create a raid10 disk.
+ 1. Boot into VRoC controller in uEFI Setup and create a raid10 disk.
- 2. Install Ubuntu 18.04.5 on the RAID10.
+ 2. Install Ubuntu 18.04.5 on the RAID10.
- 3. The system hangs at "Partitions formatting 33%".
-
+ 3. The system hangs at "Partitions formatting 33%".
After looking at the launchpad
(https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1896578/), the fix
was included in the updated kernel.
- [Quotes from the launchpad]
+ [Quotes from the launchpad]
- The released kernels are:
+ The released kernels are:
- Hirsute: 5.11.0-22-generic
- Groovy: 5.8.0-59-generic
- Focal: 5.4.0-77-generic
- Bionic: 4.15.0-147-generic
+ Hirsute: 5.11.0-22-generic
+ Groovy: 5.8.0-59-generic
+ Focal: 5.4.0-77-generic
+ Bionic: 4.15.0-147-generic
-
-
- I've asked them to also confirm this on 20.04.2, and check that 20.04.3
dailies fix the issue.
+ I've asked them to also confirm this on 20.04.2, and check that 20.04.3
+ dailies fix the issue.
It is at least a very reasonable hypothesis that this will also break on
all current ISO installs as none of them are respun once released to
include updated SRUs in the installation media. This currently affects
20.04.2 but that will be resolved shortly when 20.04.3 releases as the
GA and HWE kernels in that image should have the SRU that fixes this
issue. However, 18.04 has no further releases, and even the 18.04.5
daily-live and daily images on cdimages.ubuntu.com are not built after
18.04.5 was released.
** Description changed:
[Impact]
A hardware partner discovered they were unable to install Ubuntu on some
servers using VROC setups. They point to this issue involving DMAR that
is blocking discovery of the VROC RAID devices:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2565e5b69c44b4e42469afea3cc5a97e74d1ed45
`git bisect` points to this offending commit ee81ee84f873 ("PCI:
vmd: Disable MSI-X remapping when possible"), which disables VMD MSI
remapping. The IOMMU hardware blocks the compatibility format
interrupt request because Interrupt Remapping Enable Status (IRES) and
Extended Interrupt Mode Enable (EIME) are enabled. Please refer to
section "5.1.4 Interrupt-Remapping Hardware Operation" in Intel VT-d
spec.
To fix the issue, VMD driver still enables the interrupt remapping
irrespective of VMD_FEAT_CAN_BYPASS_MSI_REMAP if the IOMMU subsystem
enables the interrupt remapping.
[Fix]
2565e5b69c44 PCI: vmd: Do not disable MSI-X remapping if interrupt
remapping is enabled by IOMMU
[Test Plan]
1. Boot into VRoC controller in uEFI Setup and create a raid10 disk.
2. Install affected Ubuntu release on the RAID10.
3. The system hangs at "Partitions formatting 33%".
[Where problems could occur]
The fix itself is a very small change to drivers/pci/controller/vmd.c
- and problems should not occur, the patch has been tested and accepted
- upstream as of 5.16.
+ and problems should not occur. The root cause was discovered by the
+ hardware partner's engineers, who tested and submitted it upstream where
+ it was accepted and landed in 5.16.
That said, I doubt this will fix 18.04.6 as it would require a respin to
get the patched kernel onto the ISO. 20.04 should pick it up in ISO in
20.04.5, so there could still be the initial issue since those ISOs
would be lacking the patched kernel.
[Other Info]
As noted, this would need to not only land in the kernel but land in the
kernel in the ISO to resolve the issue in the installation process.
I'll bring this back as far as Focal with the expectation that while
20.04.4 is too late, it will be present using the GA kernel in 20.04.5
later on.
-
*************************************************************************
-
Original Bug Summary:
A hardware partner has been testing 18.04 subiquity images on their
servers with VROC enabled and configured in a RAID 10 setup.
In their own words:
Steps to reproduce:
1. Boot into VRoC controller in uEFI Setup and create a raid10 disk.
2. Install Ubuntu 18.04.5 on the RAID10.
3. The system hangs at "Partitions formatting 33%".
After looking at the launchpad
(https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1896578/), the fix
was included in the updated kernel.
[Quotes from the launchpad]
The released kernels are:
Hirsute: 5.11.0-22-generic
Groovy: 5.8.0-59-generic
Focal: 5.4.0-77-generic
Bionic: 4.15.0-147-generic
I've asked them to also confirm this on 20.04.2, and check that 20.04.3
dailies fix the issue.
It is at least a very reasonable hypothesis that this will also break on
all current ISO installs as none of them are respun once released to
include updated SRUs in the installation media. This currently affects
20.04.2 but that will be resolved shortly when 20.04.3 releases as the
GA and HWE kernels in that image should have the SRU that fixes this
issue. However, 18.04 has no further releases, and even the 18.04.5
daily-live and daily images on cdimages.ubuntu.com are not built after
18.04.5 was 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/1937295
Title:
PCI: vmd: Do not disable MSI-X remapping if interrupt remapping is
enabled by IOMMU
Status in subiquity:
Incomplete
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Bionic:
Invalid
Status in linux source package in Focal:
In Progress
Status in linux source package in Impish:
In Progress
Status in linux source package in Jammy:
In Progress
Bug description:
[Impact]
A hardware partner discovered they were unable to install Ubuntu on
some servers using VROC setups. They point to this issue involving
DMAR that is blocking discovery of the VROC RAID devices:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2565e5b69c44b4e42469afea3cc5a97e74d1ed45
`git bisect` points to this offending commit ee81ee84f873 ("PCI:
vmd: Disable MSI-X remapping when possible"), which disables VMD MSI
remapping. The IOMMU hardware blocks the compatibility format
interrupt request because Interrupt Remapping Enable Status (IRES) and
Extended Interrupt Mode Enable (EIME) are enabled. Please refer to
section "5.1.4 Interrupt-Remapping Hardware Operation" in Intel VT-d
spec.
To fix the issue, VMD driver still enables the interrupt remapping
irrespective of VMD_FEAT_CAN_BYPASS_MSI_REMAP if the IOMMU subsystem
enables the interrupt remapping.
[Fix]
2565e5b69c44 PCI: vmd: Do not disable MSI-X remapping if interrupt
remapping is enabled by IOMMU
[Test Plan]
1. Boot into VRoC controller in uEFI Setup and create a raid10 disk.
2. Install affected Ubuntu release on the RAID10.
3. The system hangs at "Partitions formatting 33%".
[Where problems could occur]
The fix itself is a very small change to drivers/pci/controller/vmd.c
and problems should not occur. The root cause was discovered by the
hardware partner's engineers, who tested and submitted it upstream
where it was accepted and landed in 5.16.
That said, I doubt this will fix 18.04.6 as it would require a respin
to get the patched kernel onto the ISO. 20.04 should pick it up in
ISO in 20.04.5, so there could still be the initial issue since those
ISOs would be lacking the patched kernel.
[Other Info]
As noted, this would need to not only land in the kernel but land in
the kernel in the ISO to resolve the issue in the installation
process. I'll bring this back as far as Focal with the expectation
that while 20.04.4 is too late, it will be present using the GA kernel
in 20.04.5 later on.
*************************************************************************
Original Bug Summary:
A hardware partner has been testing 18.04 subiquity images on their
servers with VROC enabled and configured in a RAID 10 setup.
In their own words:
Steps to reproduce:
1. Boot into VRoC controller in uEFI Setup and create a raid10
disk.
2. Install Ubuntu 18.04.5 on the RAID10.
3. The system hangs at "Partitions formatting 33%".
After looking at the launchpad
(https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1896578/), the
fix was included in the updated kernel.
[Quotes from the launchpad]
The released kernels are:
Hirsute: 5.11.0-22-generic
Groovy: 5.8.0-59-generic
Focal: 5.4.0-77-generic
Bionic: 4.15.0-147-generic
I've asked them to also confirm this on 20.04.2, and check that
20.04.3 dailies fix the issue.
It is at least a very reasonable hypothesis that this will also break
on all current ISO installs as none of them are respun once released
to include updated SRUs in the installation media. This currently
affects 20.04.2 but that will be resolved shortly when 20.04.3
releases as the GA and HWE kernels in that image should have the SRU
that fixes this issue. However, 18.04 has no further releases, and
even the 18.04.5 daily-live and daily images on cdimages.ubuntu.com
are not built after 18.04.5 was released.
To manage notifications about this bug go to:
https://bugs.launchpad.net/subiquity/+bug/1937295/+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
