Re: [PATCH] Fix boot hang caused by buggy TPM support in some EFI firmwares
On Mon, May 18, 2020 at 3:48 PM Don Zickus wrote:
> Hi Javier,
>
> We update the fedora kernel process to use a git tree to submit patches
> now.
>
This was a request for stable, which doesn't follow this process. Javier
asked before he sent it here. It has been added and included in the 5.6.13
builds.
Justin
>
> Can I ask you to spend a few minutes to read over the new steps
>
> https://cki-project.gitlab.io/kernel-ark/submitting-contributions.html
>
> and resubmit your request as a merge request?
>
> Hopefully after the initial setup, the steps are simple enough.
>
> Thanks in advance!
>
> Cheers,
> Don
>
>
> On Thu, May 14, 2020 at 05:44:56PM +0200, Javier Martinez Canillas wrote:
> > ---
> > kernel.spec | 3 +
> > ...log-version-before-reading-final-eve.patch | 76 +++
> > 2 files changed, 79 insertions(+)
> > create mode 100644
> tpm-check-event-log-version-before-reading-final-eve.patch
> >
> > diff --git a/kernel.spec b/kernel.spec
> > index ce66ad47a5b..6ee76a76dbb 100644
> > --- a/kernel.spec
> > +++ b/kernel.spec
> > @@ -911,6 +911,9 @@ Patch512:
> drm-dp_mst-Fix-drm_dp_send_dpcd_write-return-code.patch
> > # CVE-2020-10711 rhbz 1825116 1834778
> > Patch513: net-netlabel-cope-with-NULL-catmap.patch
> >
> > +# https://bugzilla.redhat.com/show_bug.cgi?id=1779611
> > +Patch514: tpm-check-event-log-version-before-reading-final-eve.patch
> > +
> > # END OF PATCH DEFINITIONS
> >
> > %endif
> > diff --git a/tpm-check-event-log-version-before-reading-final-eve.patch
> b/tpm-check-event-log-version-before-reading-final-eve.patch
> > new file mode 100644
> > index 000..49010406034
> > --- /dev/null
> > +++ b/tpm-check-event-log-version-before-reading-final-eve.patch
> > @@ -0,0 +1,76 @@
> > +From Mon Sep 17 00:00:00 2001
> > +From: =?UTF-8?q?Lo=C3=AFc=20Yhuel?=
> > +Date: Tue, 12 May 2020 06:01:13 +0200
> > +Subject: [PATCH] tpm: check event log version before reading final
> events
> > +MIME-Version: 1.0
> > +Content-Type: text/plain; charset=UTF-8
> > +Content-Transfer-Encoding: 8bit
> > +
> > +This fixes the boot issues since 5.3 on several Dell models when the TPM
> > +is enabled. Depending on the exact grub binary, booting the kernel would
> > +freeze early, or just report an error parsing the final events log.
> > +
> > +We get an event log in the SHA-1 format, which doesn't have a
> > +tcg_efi_specid_event_head in the first event, and there is a final
> events
> > +table which doesn't match the crypto agile format.
> > +__calc_tpm2_event_size reads bad "count" and "efispecid->num_algs", and
> > +either fails, or loops long enough for the machine to be appear frozen.
> > +
> > +So we now only parse the final events table, which is per the spec
> always
> > +supposed to be in the crypto agile format, when we got a event log in
> this
> > +format.
> > +
> > +Fixes: c46f3405692de ("tpm: Reserve the TPM final events table")
> > +Fixes: 166a2809d65b2 ("tpm: Don't duplicate events from the final event
> log in the TCG2 log")
> > +Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1779611
> > +Signed-off-by: Loïc Yhuel
> > +Link:
> https://lore.kernel.org/r/20200512040113.277768-1-loic.yh...@gmail.com
> > +Reviewed-by: Javier Martinez Canillas
> > +Reviewed-by: Jerry Snitselaar
> > +Reviewed-by: Matthew Garrett
> > +Signed-off-by: Ard Biesheuvel
> > +---
> > + drivers/firmware/efi/libstub/tpm.c | 5 +++--
> > + drivers/firmware/efi/tpm.c | 3 ++-
> > + 2 files changed, 5 insertions(+), 3 deletions(-)
> > +
> > +diff --git a/drivers/firmware/efi/libstub/tpm.c
> b/drivers/firmware/efi/libstub/tpm.c
> > +index 1d59e103a2e..e9a684637b7 100644
> > +--- a/drivers/firmware/efi/libstub/tpm.c
> > b/drivers/firmware/efi/libstub/tpm.c
> > +@@ -54,7 +54,7 @@ void efi_retrieve_tpm2_eventlog(void)
> > + efi_status_t status;
> > + efi_physical_addr_t log_location = 0, log_last_entry = 0;
> > + struct linux_efi_tpm_eventlog *log_tbl = NULL;
> > +-struct efi_tcg2_final_events_table *final_events_table;
> > ++struct efi_tcg2_final_events_table *final_events_table = NULL;
> > + unsigned long first_entry_addr, last_entry_addr;
> > + size_t log_size, last_entry_size;
> > + efi_bool_t truncated;
> > +@@ -127,7 +127,8 @@ void efi_retrieve_tpm2_eventlog(void)
> > + * Figure out whether any events have already been logged to the
> > + * final events structure, and if so how much space they take up
> > + */
> > +-final_events_table =
> get_efi_config_table(LINUX_EFI_TPM_FINAL_LOG_GUID);
> > ++if (version == EFI_TCG2_EVENT_LOG_FORMAT_TCG_2)
> > ++final_events_table =
> get_efi_config_table(LINUX_EFI_TPM_FINAL_LOG_GUID);
> > + if (final_events_table && final_events_table->nr_events) {
> > + struct tcg_pcr_event2_head *header;
> > + int offset;
> > +diff --git a/drivers/firmware/efi/tpm.c
Re: [ARK PATCHv2] x86: Fix compile issues with rh_check_supported()
From: Don Zickus on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/362#note_344755261 Dropped patch1 because internally Red Hat may drop the whole patch anyway. Let's just fix the Fedora compile problem for now. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[ARK PATCHv2] x86: Fix compile issues with rh_check_supported()
From: Don Zickus
Upstream status: RHEL only
The function rh_check_supported is a RHEL function to limit the
platforms RHEL does not want to support.
To avoid imposing this requirement on Fedora, the function was
wrapped with CONFIG_RHEL_DIFFERENCES so Fedora can disable this.
However, this has a few compile warnings that need to be cleaned up
when disabled.
Move CONFIG_RHEL_DIFFERENCES to include the functions themselves
instead of the call. As the unused functions created warnings.
V2: modified stub definition
Signed-off-by: Don Zickus
---
arch/x86/kernel/setup.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 0fd824c4162d..a7bf9730a2ca 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -750,6 +750,7 @@ static void __init trim_low_memory_range(void)
memblock_reserve(0, ALIGN(reserve_low, PAGE_SIZE));
}
+#ifdef CONFIG_RHEL_DIFFERENCES
static bool valid_amd_processor(__u8 family, const char *model_id)
{
bool valid;
@@ -874,6 +875,9 @@ static void rh_check_supported(void)
if (acpi_disabled && !guest)
pr_crit("ACPI has been disabled or is not available on this
hardware. This may result in a single cpu boot, incorrect PCI IRQ routing, or
boot failure.\n");
}
+#else
+#define rh_check_supported()
+#endif
/*
* Dump out kernel offset information on panic.
@@ -1366,9 +1370,7 @@ void __init setup_arch(char **cmdline_p)
efi_apply_memmap_quirks();
#endif
-#ifdef CONFIG_RHEL_DIFFERENCES
rh_check_supported();
-#endif
unwind_init();
}
--
2.26.2
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [OS-BUILD PATCH] Drop the static path configuration for the Sphinx docs
On Mon, May 18, 2020 at 04:42:59PM -0400, Don Zickus wrote:
> On Mon, May 18, 2020 at 07:42:26PM -, GitLab Bridge on behalf of
> jeremycline wrote:
> > From: Jeremy Cline
> >
> > There are no static files at this time. I don't know the first thing
> > about CSS and rely on my elders and betters to make the documentation
> > look presentable. Configuring a static directory also generates a Sphinx
> > warning when it isn't present (which it isn't on clean checkouts because
> > it's empty) so just remove it.
> >
> > Signed-off-by: Jeremy Cline
> > ---
> > redhat/docs/conf.py | 5 -
> > 1 file changed, 5 deletions(-)
> >
> > diff --git a/redhat/docs/conf.py b/redhat/docs/conf.py
> > index b5e60902cd65..d873a31d984d 100644
> > --- a/redhat/docs/conf.py
> > +++ b/redhat/docs/conf.py
> > @@ -40,8 +40,3 @@ html_theme_options = {
> > "show_related": True,
> > "sidebar_collapse": True,
> > }
> > -
> > -# Add any paths that contain custom static files (such as style sheets)
> > here,
> > -# relative to this directory. They are copied after the builtin static
> > files,
> > -# so a file named "default.css" will overwrite the builtin "default.css".
> > -html_static_path = ["_static"]
>
> I assume you will update the gitlab-ci.yml file in kernel-ark-ci next?
>
I've updated the CI[0] and it can be merged after this is accepted.
[0] https://gitlab.com/cki-project/kernel-ark-ci/-/merge_requests/2
> Acked-by: Don Zickus
>
> > --
> > 2.26.2
> > ___
> > kernel mailing list -- kernel@lists.fedoraproject.org
> > To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
>
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: [PATCH] Fix boot hang caused by buggy TPM support in some EFI firmwares
Hi Javier,
We update the fedora kernel process to use a git tree to submit patches now.
Can I ask you to spend a few minutes to read over the new steps
https://cki-project.gitlab.io/kernel-ark/submitting-contributions.html
and resubmit your request as a merge request?
Hopefully after the initial setup, the steps are simple enough.
Thanks in advance!
Cheers,
Don
On Thu, May 14, 2020 at 05:44:56PM +0200, Javier Martinez Canillas wrote:
> ---
> kernel.spec | 3 +
> ...log-version-before-reading-final-eve.patch | 76 +++
> 2 files changed, 79 insertions(+)
> create mode 100644 tpm-check-event-log-version-before-reading-final-eve.patch
>
> diff --git a/kernel.spec b/kernel.spec
> index ce66ad47a5b..6ee76a76dbb 100644
> --- a/kernel.spec
> +++ b/kernel.spec
> @@ -911,6 +911,9 @@ Patch512:
> drm-dp_mst-Fix-drm_dp_send_dpcd_write-return-code.patch
> # CVE-2020-10711 rhbz 1825116 1834778
> Patch513: net-netlabel-cope-with-NULL-catmap.patch
>
> +# https://bugzilla.redhat.com/show_bug.cgi?id=1779611
> +Patch514: tpm-check-event-log-version-before-reading-final-eve.patch
> +
> # END OF PATCH DEFINITIONS
>
> %endif
> diff --git a/tpm-check-event-log-version-before-reading-final-eve.patch
> b/tpm-check-event-log-version-before-reading-final-eve.patch
> new file mode 100644
> index 000..49010406034
> --- /dev/null
> +++ b/tpm-check-event-log-version-before-reading-final-eve.patch
> @@ -0,0 +1,76 @@
> +From Mon Sep 17 00:00:00 2001
> +From: =?UTF-8?q?Lo=C3=AFc=20Yhuel?=
> +Date: Tue, 12 May 2020 06:01:13 +0200
> +Subject: [PATCH] tpm: check event log version before reading final events
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +
> +This fixes the boot issues since 5.3 on several Dell models when the TPM
> +is enabled. Depending on the exact grub binary, booting the kernel would
> +freeze early, or just report an error parsing the final events log.
> +
> +We get an event log in the SHA-1 format, which doesn't have a
> +tcg_efi_specid_event_head in the first event, and there is a final events
> +table which doesn't match the crypto agile format.
> +__calc_tpm2_event_size reads bad "count" and "efispecid->num_algs", and
> +either fails, or loops long enough for the machine to be appear frozen.
> +
> +So we now only parse the final events table, which is per the spec always
> +supposed to be in the crypto agile format, when we got a event log in this
> +format.
> +
> +Fixes: c46f3405692de ("tpm: Reserve the TPM final events table")
> +Fixes: 166a2809d65b2 ("tpm: Don't duplicate events from the final event log
> in the TCG2 log")
> +Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1779611
> +Signed-off-by: Loïc Yhuel
> +Link: https://lore.kernel.org/r/20200512040113.277768-1-loic.yh...@gmail.com
> +Reviewed-by: Javier Martinez Canillas
> +Reviewed-by: Jerry Snitselaar
> +Reviewed-by: Matthew Garrett
> +Signed-off-by: Ard Biesheuvel
> +---
> + drivers/firmware/efi/libstub/tpm.c | 5 +++--
> + drivers/firmware/efi/tpm.c | 3 ++-
> + 2 files changed, 5 insertions(+), 3 deletions(-)
> +
> +diff --git a/drivers/firmware/efi/libstub/tpm.c
> b/drivers/firmware/efi/libstub/tpm.c
> +index 1d59e103a2e..e9a684637b7 100644
> +--- a/drivers/firmware/efi/libstub/tpm.c
> b/drivers/firmware/efi/libstub/tpm.c
> +@@ -54,7 +54,7 @@ void efi_retrieve_tpm2_eventlog(void)
> + efi_status_t status;
> + efi_physical_addr_t log_location = 0, log_last_entry = 0;
> + struct linux_efi_tpm_eventlog *log_tbl = NULL;
> +-struct efi_tcg2_final_events_table *final_events_table;
> ++struct efi_tcg2_final_events_table *final_events_table = NULL;
> + unsigned long first_entry_addr, last_entry_addr;
> + size_t log_size, last_entry_size;
> + efi_bool_t truncated;
> +@@ -127,7 +127,8 @@ void efi_retrieve_tpm2_eventlog(void)
> + * Figure out whether any events have already been logged to the
> + * final events structure, and if so how much space they take up
> + */
> +-final_events_table = get_efi_config_table(LINUX_EFI_TPM_FINAL_LOG_GUID);
> ++if (version == EFI_TCG2_EVENT_LOG_FORMAT_TCG_2)
> ++final_events_table =
> get_efi_config_table(LINUX_EFI_TPM_FINAL_LOG_GUID);
> + if (final_events_table && final_events_table->nr_events) {
> + struct tcg_pcr_event2_head *header;
> + int offset;
> +diff --git a/drivers/firmware/efi/tpm.c b/drivers/firmware/efi/tpm.c
> +index 55b031d2c98..77e101a395e 100644
> +--- a/drivers/firmware/efi/tpm.c
> b/drivers/firmware/efi/tpm.c
> +@@ -62,7 +62,8 @@ int __init efi_tpm_eventlog_init(void)
> + tbl_size = sizeof(*log_tbl) + log_tbl->size;
> + memblock_reserve(efi.tpm_log, tbl_size);
> +
> +-if (efi.tpm_final_log == EFI_INVALID_TABLE_ADDR)
> ++if (efi.tpm_final_log == EFI_INVALID_TABLE_ADDR ||
> ++
Re: [OS-BUILD PATCH] Drop the static path configuration for the Sphinx docs
On Mon, May 18, 2020 at 07:42:26PM -, GitLab Bridge on behalf of
jeremycline wrote:
> From: Jeremy Cline
>
> There are no static files at this time. I don't know the first thing
> about CSS and rely on my elders and betters to make the documentation
> look presentable. Configuring a static directory also generates a Sphinx
> warning when it isn't present (which it isn't on clean checkouts because
> it's empty) so just remove it.
>
> Signed-off-by: Jeremy Cline
> ---
> redhat/docs/conf.py | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/redhat/docs/conf.py b/redhat/docs/conf.py
> index b5e60902cd65..d873a31d984d 100644
> --- a/redhat/docs/conf.py
> +++ b/redhat/docs/conf.py
> @@ -40,8 +40,3 @@ html_theme_options = {
> "show_related": True,
> "sidebar_collapse": True,
> }
> -
> -# Add any paths that contain custom static files (such as style sheets) here,
> -# relative to this directory. They are copied after the builtin static files,
> -# so a file named "default.css" will overwrite the builtin "default.css".
> -html_static_path = ["_static"]
I assume you will update the gitlab-ci.yml file in kernel-ark-ci next?
Acked-by: Don Zickus
> --
> 2.26.2
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCH] Drop the static path configuration for the Sphinx docs
From: Jeremy Cline
There are no static files at this time. I don't know the first thing
about CSS and rely on my elders and betters to make the documentation
look presentable. Configuring a static directory also generates a Sphinx
warning when it isn't present (which it isn't on clean checkouts because
it's empty) so just remove it.
Signed-off-by: Jeremy Cline
---
redhat/docs/conf.py | 5 -
1 file changed, 5 deletions(-)
diff --git a/redhat/docs/conf.py b/redhat/docs/conf.py
index b5e60902cd65..d873a31d984d 100644
--- a/redhat/docs/conf.py
+++ b/redhat/docs/conf.py
@@ -40,8 +40,3 @@ html_theme_options = {
"show_related": True,
"sidebar_collapse": True,
}
-
-# Add any paths that contain custom static files (such as style sheets) here,
-# relative to this directory. They are copied after the builtin static files,
-# so a file named "default.css" will overwrite the builtin "default.css".
-html_static_path = ["_static"]
--
2.26.2
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
✅ PASS: Test report for kernel 5.7.0-0.rc6.1.cki.fc33 (ark)
Hello, We ran automated tests on a recent commit from this kernel tree: Kernel repo: https://gitlab.com/cki-project/kernel-ark.git Commit: e94772f8cab7 - [redhat] kernel-5.7.0-0.rc6.1 The results of these automated tests are provided below. Overall result: PASSED Merge: OK Compile: OK Tests: OK All kernel binaries, config files, and logs are available for download here: https://cki-artifacts.s3.us-east-2.amazonaws.com/index.html?prefix=datawarehouse/2020/05/18/570597 Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' __ Compile testing --- We compiled the kernel for 4 architectures: aarch64: rpmbuild arguments: rpmbuild --target aarch64 --with=cross --with=kabidw_base --without=bpftool --without=selftests --without=debug --without=ipaclones --without=perf --without=tools ppc64le: rpmbuild arguments: rpmbuild --target ppc64le --with=cross --with=kabidw_base --without=bpftool --without=selftests --without=debug --without=ipaclones --without=perf --without=tools s390x: rpmbuild arguments: rpmbuild --target s390x --with=cross --with=kabidw_base --without=bpftool --without=selftests --without=debug --without=ipaclones --without=perf --without=tools x86_64: rpmbuild arguments: rpmbuild --target x86_64 --with=bpftool --with=selftests --with=kabidw_base --without=debug --without=ipaclones --without=perf --without=tools Hardware testing We booted each kernel and ran the following tests: aarch64: Host 1: ⚡ Internal infrastructure issues prevented one or more tests (marked with ⚡⚡⚡) from running on this architecture. This is not the fault of the kernel that was tested. ✅ Boot test ⚡⚡⚡ kdump - sysrq-c Host 2: ⚡ Internal infrastructure issues prevented one or more tests (marked with ⚡⚡⚡) from running on this architecture. This is not the fault of the kernel that was tested. ✅ Boot test ✅ xfstests - ext4 ⚡⚡⚡ xfstests - xfs ⚡⚡⚡ selinux-policy: serge-testsuite ⚡⚡⚡ lvm thinp sanity ⚡⚡⚡ storage: software RAID testing ⚡⚡⚡ stress: stress-ng ⚡⚡⚡ IPMI driver test ⚡⚡⚡ IPMItool loop stress test ⚡⚡⚡ Storage blktests ⚡⚡⚡ storage: iSCSI parameters ppc64le: Host 1: ✅ Boot test ✅ kdump - sysrq-c Host 2: ⚡ Internal infrastructure issues prevented one or more tests (marked with ⚡⚡⚡) from running on this architecture. This is not the fault of the kernel that was tested. ✅ Boot test ⚡⚡⚡ LTP ⚡⚡⚡ Loopdev Sanity ⚡⚡⚡ Memory function: memfd_create ⚡⚡⚡ AMTU (Abstract Machine Test Utility) ⚡⚡⚡ Networking bridge: sanity ⚡⚡⚡ Ethernet drivers sanity ⚡⚡⚡ Networking MACsec: sanity ⚡⚡⚡ Networking socket: fuzz ⚡⚡⚡ Networking: ipv6/Fujitsu-socketapi-test ⚡⚡⚡ Networking sctp-auth: sockopts test ⚡⚡⚡ Networking route: pmtu ⚡⚡⚡ Networking route_func - local ⚡⚡⚡ Networking route_func - forward ⚡⚡⚡ Networking TCP: keepalive test ⚡⚡⚡ Networking UDP: socket ⚡⚡⚡ Networking tunnel: geneve basic test ⚡⚡⚡ Networking tunnel: gre basic ⚡⚡⚡ L2TP basic test ⚡⚡⚡ Networking tunnel: vxlan basic ⚡⚡⚡ Networking ipsec: basic netns - tunnel ⚡⚡⚡ Libkcapi AF_ALG test ⚡⚡⚡ pciutils: update pci ids test ⚡⚡⚡ ALSA PCM loopback test ⚡⚡⚡ ALSA Control (mixer) Userspace Element test ⚡⚡⚡ Usex - version 1.9-29 ⚡⚡⚡ CIFS Connectathon ⚡⚡⚡ POSIX pjd-fstest suites ⚡⚡⚡ Memory function: kaslr ⚡⚡⚡ LTP: openposix test suite ⚡⚡⚡ Networking firewall: basic netfilter test ⚡⚡⚡ audit: audit testsuite test ⚡⚡⚡ storage: dm/common ⚡⚡⚡ trace: ftrace/tracer ⚡⚡⚡ Libhugetlbfs - version 2.2.1 s390x: Host 1: ✅ Boot test ✅ kdump - sysrq-c Host 2: ⚡ Internal infrastructure issues prevented one or more tests (marked with ⚡⚡⚡) from running on this architecture. This is not the fault of the kernel that was tested. ⚡⚡⚡ Boot test ⚡⚡⚡ selinux-policy: serge-testsuite ⚡⚡⚡ stress: stress-ng ⚡⚡⚡ Storage blktests x86_64: Host 1: ✅ Boot test ❌ kdump - sysrq-c Host 2: ⚡ Internal infrastructure issues prevented one or more tests (marked with ⚡⚡⚡) from running on this architecture. This is not the fault of the kernel that was tested. ⚡⚡⚡ Boot test ⚡⚡⚡
Re: Stability issue with jetson-tk1NIC with 5.3+
> > > FYI, I've experienced a stability issue with the jetson-tk1 NIC since > > > kernel 5.3 and later. > > > This is reported upstream at > > > https://bugzilla.kernel.org/show_bug.cgi?id=206217 > > > To sum-up: under some "MMC and network I/O load" (dnf update or scp of > > > large file), the pciport receives AER errors that are actually fatal > > > to the network interface and cannot be recovered unless a reboot. > > > > > > I've bisected the issue and found the commit that once reverted, > > > restore a good behaviour: > > > https://patchwork.ozlabs.org/project/linux-tegra/patch/20200420164304.28810-1-kwiz...@gmail.com/ > > > I haven't experienced any other regression since then. > > > > > > What I would like to ask is: > > > 1/ Is there any others reproducers for this issue on jetson-tk1 ? > > > (issue only relevant on tegra124 SOC). > > > 2/ As upstream agreed that a revert would be preferred until more > > > investigation, can we consider to apply as a downstream patch until > > > then ? > > > > I have on issues with the patch being applied. > > > > I assume this is no issues? I will pick it up with 5.6.14. Correct ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Stability issue with jetson-tk1NIC with 5.3+
On Mon, May 18, 2020 at 5:09 AM Peter Robinson wrote: > > > FYI, I've experienced a stability issue with the jetson-tk1 NIC since > > kernel 5.3 and later. > > This is reported upstream at > > https://bugzilla.kernel.org/show_bug.cgi?id=206217 > > To sum-up: under some "MMC and network I/O load" (dnf update or scp of > > large file), the pciport receives AER errors that are actually fatal > > to the network interface and cannot be recovered unless a reboot. > > > > I've bisected the issue and found the commit that once reverted, > > restore a good behaviour: > > https://patchwork.ozlabs.org/project/linux-tegra/patch/20200420164304.28810-1-kwiz...@gmail.com/ > > I haven't experienced any other regression since then. > > > > What I would like to ask is: > > 1/ Is there any others reproducers for this issue on jetson-tk1 ? > > (issue only relevant on tegra124 SOC). > > 2/ As upstream agreed that a revert would be preferred until more > > investigation, can we consider to apply as a downstream patch until > > then ? > > I have on issues with the patch being applied. > I assume this is no issues? I will pick it up with 5.6.14. Thanks, Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Stability issue with jetson-tk1NIC with 5.3+
> FYI, I've experienced a stability issue with the jetson-tk1 NIC since > kernel 5.3 and later. > This is reported upstream at > https://bugzilla.kernel.org/show_bug.cgi?id=206217 > To sum-up: under some "MMC and network I/O load" (dnf update or scp of > large file), the pciport receives AER errors that are actually fatal > to the network interface and cannot be recovered unless a reboot. > > I've bisected the issue and found the commit that once reverted, > restore a good behaviour: > https://patchwork.ozlabs.org/project/linux-tegra/patch/20200420164304.28810-1-kwiz...@gmail.com/ > I haven't experienced any other regression since then. > > What I would like to ask is: > 1/ Is there any others reproducers for this issue on jetson-tk1 ? > (issue only relevant on tegra124 SOC). > 2/ As upstream agreed that a revert would be preferred until more > investigation, can we consider to apply as a downstream patch until > then ? I have on issues with the patch being applied. Peter ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[ARK PATCH] pwm: lpss: Fix get_state runtime-pm reference handling
From: Hans de Goede
Before commit cfc4c189bc70 ("pwm: Read initial hardware state at request
time"), a driver's get_state callback would get called once per PWM from
pwmchip_add().
pwm-lpss' runtime-pm code was relying on this, getting a runtime-pm ref for
PWMs which are enabled at probe time from within its get_state callback,
before enabling runtime-pm.
The change to calling get_state at request time causes a number of
problems:
1. PWMs enabled at probe time may get runtime suspended before they are
requested, causing e.g. a LCD backlight controlled by the PWM to turn off.
2. When the request happens when the PWM has been runtime suspended, the
ctrl register will read all 1 / 0x, causing get_state to store
bogus values in the pwm_state.
3. get_state was using an async pm_runtime_get() call, because it assumed
that runtime-pm has not been enabled yet. If shortly after the request an
apply call is made, then the pwm_lpss_is_updating() check may trigger
because the resume triggered by the pm_runtime_get() call is not complete
yet, so the ctrl register still reads all 1 / 0x.
This commit fixes these issues by moving the initial pm_runtime_get() call
for PWMs which are enabled at probe time to the pwm_lpss_probe() function;
and by making get_state take a runtime-pm ref before reading the ctrl reg.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1828927
Fixes: cfc4c189bc70 ("pwm: Read initial hardware state at request time")
Cc: sta...@vger.kernel.org
Reviewed-by: Andy Shevchenko
Signed-off-by: Hans de Goede
Upstream Status:
https://lore.kernel.org/linux-acpi/5f15f6bc-8650-d86e-893f-0d41557c5...@redhat.com/
---
drivers/pwm/pwm-lpss.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 75bbfe5f3bc2..9d965ffe66d1 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -158,7 +158,6 @@ static int pwm_lpss_apply(struct pwm_chip *chip, struct
pwm_device *pwm,
return 0;
}
-/* This function gets called once from pwmchip_add to get the initial state */
static void pwm_lpss_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
struct pwm_state *state)
{
@@ -167,6 +166,8 @@ static void pwm_lpss_get_state(struct pwm_chip *chip,
struct pwm_device *pwm,
unsigned long long base_unit, freq, on_time_div;
u32 ctrl;
+ pm_runtime_get_sync(chip->dev);
+
base_unit_range = BIT(lpwm->info->base_unit_bits);
ctrl = pwm_lpss_read(pwm);
@@ -187,8 +188,7 @@ static void pwm_lpss_get_state(struct pwm_chip *chip,
struct pwm_device *pwm,
state->polarity = PWM_POLARITY_NORMAL;
state->enabled = !!(ctrl & PWM_ENABLE);
- if (state->enabled)
- pm_runtime_get(chip->dev);
+ pm_runtime_put(chip->dev);
}
static const struct pwm_ops pwm_lpss_ops = {
@@ -202,7 +202,8 @@ struct pwm_lpss_chip *pwm_lpss_probe(struct device *dev,
struct resource *r,
{
struct pwm_lpss_chip *lpwm;
unsigned long c;
- int ret;
+ int i, ret;
+ u32 ctrl;
if (WARN_ON(info->npwm > MAX_PWMS))
return ERR_PTR(-ENODEV);
@@ -232,6 +233,12 @@ struct pwm_lpss_chip *pwm_lpss_probe(struct device *dev,
struct resource *r,
return ERR_PTR(ret);
}
+ for (i = 0; i < lpwm->info->npwm; i++) {
+ ctrl = pwm_lpss_read(>chip.pwms[i]);
+ if (ctrl & PWM_ENABLE)
+ pm_runtime_get(dev);
+ }
+
return lpwm;
}
EXPORT_SYMBOL_GPL(pwm_lpss_probe);
--
2.26.2
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Stability issue with jetson-tk1NIC with 5.3+
Hi there, FYI, I've experienced a stability issue with the jetson-tk1 NIC since kernel 5.3 and later. This is reported upstream at https://bugzilla.kernel.org/show_bug.cgi?id=206217 To sum-up: under some "MMC and network I/O load" (dnf update or scp of large file), the pciport receives AER errors that are actually fatal to the network interface and cannot be recovered unless a reboot. I've bisected the issue and found the commit that once reverted, restore a good behaviour: https://patchwork.ozlabs.org/project/linux-tegra/patch/20200420164304.28810-1-kwiz...@gmail.com/ I haven't experienced any other regression since then. What I would like to ask is: 1/ Is there any others reproducers for this issue on jetson-tk1 ? (issue only relevant on tegra124 SOC). 2/ As upstream agreed that a revert would be preferred until more investigation, can we consider to apply as a downstream patch until then ? Thanks for any advices on the topic. -- - Nicolas (kwizart) ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
