Bug 2229708
| Summary: | Bootup has half an hour delay on Kernel 6.4.x on Tuxedo InifityBook S15 Gen7 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | xspielinbox+redhat | ||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||
| Status: | NEW --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 38 | CC: | acaringi, adscvr, airlied, alciregi, bskeggs, hdegoede, hpa, jarod, josef, kernel-maint, lgoncalv, linville, masami256, mchehab, ptalbert, steved | ||||
| Target Milestone: | --- | Keywords: | Regression, Upgrades | ||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | Type: | --- | |||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
xspielinbox+redhat
2023-08-07 11:26:20 UTC
Created attachment 1982109 [details]
Kernel Log
The problem persists with Kernel 6.4.8-200.fc38.x86_64 and 6.4.9-200.fc38.x86_64. Have you tried contacting Tuxedo about this? Running Linux is a supported use case on their laptops and Fedora's kernel is pretty close to the upstream kernel, so I would expect them to be able to reproduce this. In my experience Tuxedo usually is pretty good in resolving Linux support issues for their laptops. I just noticed this commit which specifically fixes a problem on the TUXEDO InfinityBook S 15/17 Gen7 has been queued for 6.4.11 (which is not yet released): https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=linux-6.4.y&id=5e45622210dd8322c7ebafc44da655f6c096beb4 So I suspect that this bug will be fixed by 6.4.11 once released and picked up by Fedora in a couple of days. Thank you for the reply! Yes, this commit does seem like something that would fix my problem, though I haven't tried it yet. I did contact Tuxedo in the meantime now, but they will then probably just tell me the same then. But I am still confused how this regression was introduced in the first place. I can't find any change regarding IRQ in the last month in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/log/drivers/char/tpm/tpm_tis.c?h=linux-6.4.y I unfortunately don't understand the kernel code, but I assume, that https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/drivers/char/tpm/tpm_tis.c?h=linux-6.4.y&id=77218e83c83c1cd4b994edfb5b162ece42e73ffe must have somehow then introduced the regression? During my initial testing and research I did try some kernel cli flags, whether they resolve my issue, but interestingly enough as far as I can remember tpm_tis.interrupts=0 did not solve my issue, though it is presented as a effective workaround in the referenced SUSE bug. What are the advantages/disadvantages of IRQ and polling anyway? Wouldn't it be a better solution, if the firmware bug that everyone in the threads is talking about get's solved instead of the kernel disabling some feature? Whatever I did the last time: I tried it again and adding the tpm_tis.interrupts=0 kernel boot option does indeed work around the issue at least with Kernel 6.4.9. I also noticed that reboots do not seem to be affected at least when booting from kernel 6.4.9 to kernel 6.4.9. > I did contact Tuxedo in the meantime now, but they will then probably just tell me the same then. I'm not sure if they are aware of this fix since it was send by someone from Suse, not by someone from Tuxedo. So it would be good if you can send them another mail pointing to the fix so that they won't waste time on it. > I unfortunately don't understand the kernel code, but I assume, that https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/drivers/char/tpm/tpm_tis.c?h=linux-6.4.y&id=77218e83c83c1cd4b994edfb5b162ece42e73ffe must have somehow then introduced the regression? No this commit which in 6.4.y and not in 6.3.y causes this: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/char/tpm?h=v6.4&id=e644b2f498d297a928efcb7ff6f900c27f8b788e > What are the advantages/disadvantages of IRQ and polling anyway? polling means asking the TPM repeatedly if the last command is ready, which consumes CPU. IRQ means waiting for the TPM to signal the CPU that things are ready, allowing the CPU to do other work in the mean time. So using an IRQ usually is preferred over polling. But typically the TPM is only used a couple of times during boot and it does not see much use after that. So using polling instead of IRQ based access is not a big deal. And because of the ever growing list of devices with issues with using the IRQ, tpm_tis is actually going to move to polling by default: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/drivers/char/tpm/tpm_tis.c?h=linux-6.4.y&id=44d3baca8bcda0856fc20fb58ae4bd254d952580 Thank you for the good explanation! I notified Tuxedo. |