Activity log for bug #1879711

Date Who What changed Old value New value Message
2020-05-20 13:53:18 Andrea Righi bug added bug
2020-05-20 13:53:34 Andrea Righi nominated for series Ubuntu Focal
2020-05-20 13:53:34 Andrea Righi bug task added linux (Ubuntu Focal)
2020-05-20 13:54:21 Andrea Righi affects linux (Ubuntu) linux-aws (Ubuntu)
2020-05-20 13:54:37 Andrea Righi linux-aws (Ubuntu Focal): importance Undecided High
2020-05-20 13:54:40 Andrea Righi linux-aws (Ubuntu Focal): assignee Andrea Righi (arighi)
2020-05-20 14:02:22 Andrea Righi description [Impact] The option CONFIG_DMA_CMA seems to cause resume problems on the t2.* instance types (Xen). With this option enabled device drivers are allowed to use the Contiguous Memory Allocator (CMA) for DMA operations. So, drivers can allocate large physically-contiguous blocks of memory, instead of relying on the I/O map or scatter-gather support. However, on resume, the memory used by DMA needs to be re-initialized / re-allocated, but it may fail to allocate large chunks of contiguous memory due to the fact that we also need to restore the hibernation image, using more memory and causing a system hang during the resume process. [Test case] Hibernate / resume any t2.* instance (especially t2.nano, where the problem seems to happen 100% of the times after 2 consecutive hibernate/resume cycles). [Fix] Disable CONFIG_DMA_CMA. NOTE: this option is already disabled in the generic kernel (see LP: #1362261). [Regression potential] It is a .config change, no regression potential except with the fact that disabling this option also disables the module 'etnaviv' (Vivante graphic card), that is not really needed in the aws kernel. [Impact] The option CONFIG_DMA_CMA seems to cause resume problems on the t2.* instance types (Xen). With this option enabled device drivers are allowed to use the Contiguous Memory Allocator (CMA) for DMA operations. So, drivers can allocate large physically-contiguous blocks of memory, instead of relying on the I/O map or scatter-gather support. However, on resume, the memory used by DMA needs to be re-initialized / re-allocated, but it may fail to allocate large chunks of contiguous memory due to the fact that we also need to restore the hibernation image, using more memory and causing a system hang during the resume process. [Test case] Hibernate / resume any t2.* instance (especially t2.nano, where the problem seems to happen 100% of the times after 2 consecutive hibernate/resume cycles). [Fix] Disable CONFIG_DMA_CMA. NOTE: this option is already disabled in the generic kernel (see LP: #1362261). With this option disabled the success rate of hibernation on the t2.* instance types during our tests jumped to 100%. [Regression potential] It is a .config change, no regression potential except with the fact that disabling this option also disables the module 'etnaviv' (Vivante graphic card), that is not really needed in the aws kernel.
2020-05-20 14:02:58 Andrea Righi description [Impact] The option CONFIG_DMA_CMA seems to cause resume problems on the t2.* instance types (Xen). With this option enabled device drivers are allowed to use the Contiguous Memory Allocator (CMA) for DMA operations. So, drivers can allocate large physically-contiguous blocks of memory, instead of relying on the I/O map or scatter-gather support. However, on resume, the memory used by DMA needs to be re-initialized / re-allocated, but it may fail to allocate large chunks of contiguous memory due to the fact that we also need to restore the hibernation image, using more memory and causing a system hang during the resume process. [Test case] Hibernate / resume any t2.* instance (especially t2.nano, where the problem seems to happen 100% of the times after 2 consecutive hibernate/resume cycles). [Fix] Disable CONFIG_DMA_CMA. NOTE: this option is already disabled in the generic kernel (see LP: #1362261). With this option disabled the success rate of hibernation on the t2.* instance types during our tests jumped to 100%. [Regression potential] It is a .config change, no regression potential except with the fact that disabling this option also disables the module 'etnaviv' (Vivante graphic card), that is not really needed in the aws kernel. [Impact] The option CONFIG_DMA_CMA seems to cause resume problems on the t2.* instance types (Xen). With this option enabled device drivers are allowed to use the Contiguous Memory Allocator (CMA) for DMA operations. So, drivers can allocate large physically-contiguous blocks of memory, instead of relying on the I/O map or scatter-gather support. However, on resume, the memory used by DMA needs to be re-initialized / re-allocated, but it may fail to allocate large chunks of contiguous memory due to the fact that we also need to restore the hibernation image, using more memory and causing a system hang during the resume process. [Test case] Hibernate / resume any t2.* instance (especially t2.nano, where the problem seems to happen 100% of the times after 2 consecutive hibernate/resume cycles). [Fix] Disable CONFIG_DMA_CMA. NOTE: this option is already disabled in the generic kernel (see LP: #1362261). With this option disabled the success rate of hibernation on the t2.* instance types during our tests jumped to 100%. [Regression potential] It is a .config change, no regression potential except for the fact that disabling this option also disables the module 'etnaviv' (Vivante graphic card), that is not really needed in the aws kernel.
2020-05-20 14:03:57 Andrea Righi description [Impact] The option CONFIG_DMA_CMA seems to cause resume problems on the t2.* instance types (Xen). With this option enabled device drivers are allowed to use the Contiguous Memory Allocator (CMA) for DMA operations. So, drivers can allocate large physically-contiguous blocks of memory, instead of relying on the I/O map or scatter-gather support. However, on resume, the memory used by DMA needs to be re-initialized / re-allocated, but it may fail to allocate large chunks of contiguous memory due to the fact that we also need to restore the hibernation image, using more memory and causing a system hang during the resume process. [Test case] Hibernate / resume any t2.* instance (especially t2.nano, where the problem seems to happen 100% of the times after 2 consecutive hibernate/resume cycles). [Fix] Disable CONFIG_DMA_CMA. NOTE: this option is already disabled in the generic kernel (see LP: #1362261). With this option disabled the success rate of hibernation on the t2.* instance types during our tests jumped to 100%. [Regression potential] It is a .config change, no regression potential except for the fact that disabling this option also disables the module 'etnaviv' (Vivante graphic card), that is not really needed in the aws kernel. [Impact] The option CONFIG_DMA_CMA seems to cause hibernation failures on the t2.* instance types (Xen). With this option enabled device drivers are allowed to use the Contiguous Memory Allocator (CMA) for DMA operations. So, drivers can allocate large physically-contiguous blocks of memory, instead of relying on the I/O map or scatter-gather support. However, on resume, the memory used by DMA needs to be re-initialized / re-allocated, but it may fail to allocate large chunks of contiguous memory due to the fact that we also need to restore the hibernation image, using more memory and causing a system hang during the resume process. [Test case] Hibernate / resume any t2.* instance (especially t2.nano, where the problem seems to happen 100% of the times after 2 consecutive hibernate/resume cycles). [Fix] Disable CONFIG_DMA_CMA. NOTE: this option is already disabled in the generic kernel (see LP: #1362261). With this option disabled the success rate of hibernation on the t2.* instance types during our tests jumped to 100%. [Regression potential] It is a .config change, no regression potential except for the fact that disabling this option also disables the module 'etnaviv' (Vivante graphic card), that is not really needed in the aws kernel.
2020-05-25 13:21:58 Stefan Bader nominated for series Ubuntu Eoan
2020-05-25 13:21:58 Stefan Bader bug task added linux-aws (Ubuntu Eoan)
2020-05-25 13:22:13 Stefan Bader linux-aws (Ubuntu Eoan): importance Undecided High
2020-05-25 13:22:13 Stefan Bader linux-aws (Ubuntu Eoan): status New In Progress
2020-05-25 13:22:27 Stefan Bader linux-aws (Ubuntu Focal): status New In Progress
2020-05-25 13:22:38 Stefan Bader linux-aws (Ubuntu): status New Invalid
2020-06-03 13:06:08 Andrea Righi linux-aws (Ubuntu Eoan): assignee Andrea Righi (arighi)
2020-06-04 07:45:54 Khaled El Mously linux-aws (Ubuntu Eoan): status In Progress Fix Committed
2020-06-04 07:45:56 Khaled El Mously linux-aws (Ubuntu Focal): status In Progress Fix Committed
2020-07-01 10:25:42 Launchpad Janitor linux-aws (Ubuntu Focal): status Fix Committed Fix Released
2020-07-01 10:25:42 Launchpad Janitor cve linked 2020-0543
2020-07-01 10:25:42 Launchpad Janitor cve linked 2020-13143
2020-07-06 07:57:03 Launchpad Janitor linux-aws (Ubuntu Eoan): status Fix Committed Fix Released
2020-07-06 07:57:03 Launchpad Janitor cve linked 2020-10711
2020-07-28 00:56:53 Launchpad Janitor linux-aws (Ubuntu): status Invalid Fix Released
2020-07-28 00:56:53 Launchpad Janitor cve linked 2019-16089
2020-07-28 00:56:53 Launchpad Janitor cve linked 2019-19642
2020-07-28 00:56:53 Launchpad Janitor cve linked 2020-11935
2020-11-04 07:41:25 Andrea Righi nominated for series Ubuntu Groovy
2020-11-04 07:41:25 Andrea Righi bug task added linux-aws (Ubuntu Groovy)
2020-11-04 14:07:49 Stefan Bader linux-aws (Ubuntu Groovy): importance Undecided Medium
2020-11-04 14:07:49 Stefan Bader linux-aws (Ubuntu Groovy): status New In Progress
2020-11-06 16:59:42 Kleber Sacilotto de Souza linux-aws (Ubuntu Groovy): status In Progress Fix Committed
2020-12-01 17:44:23 Launchpad Janitor linux-aws (Ubuntu Groovy): status Fix Committed Fix Released