Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1816621
Summary: | Second suspend does not work | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | David Ober <dober> | ||||
Component: | kernel | Assignee: | Hans de Goede <hdegoede> | ||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 32 | CC: | airlied, besser82, bskeggs, fzatlouk, gmarr, hdegoede, ichavero, itamar, jarodwilson, jeremy, jglisse, john.j5live, jonathan, josef, kernel-maint, linville, masami256, mchehab, mihai, mjg59, mpearson, steved, tpopela | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | AcceptedFreezeException | ||||||
Fixed In Version: | kernel-5.5.15-200.fc31 kernel-5.5.16-100.fc30 | Doc Type: | If docs needed, set a value | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2020-04-07 03:23:18 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 1816645, 1705305, 1705306 | ||||||
Attachments: |
|
Canonical is referencing this as being the fix for the suspend issue From: Aaron Ma <aaron.ma> To: jeffrey.t.kirsher, aaron.ma, davem, intel-wired-lan.org, netdev.org, linux-kernel.org, sasha.neftin Subject: [PATCH] e1000e: bump up timeout to wait when ME un-configure ULP mode Date: Tue, 24 Mar 2020 03:16:39 +0800 Message-ID: <20200323191639.48826-1-aaron.ma> (raw) ME takes 2+ seconds to un-configure ULP mode done after resume from s2idle on some ThinkPad laptops. Without enough wait, reset and re-init will fail with error. Fixes: f15bb6dde738cc8fa0 ("e1000e: Add support for S0ix") BugLink: https://bugs.launchpad.net/bugs/1865570 Signed-off-by: Aaron Ma <aaron.ma> --- drivers/net/ethernet/intel/e1000e/ich8lan.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c index b4135c50e905..147b15a2f8b3 100644 --- a/drivers/net/ethernet/intel/e1000e/ich8lan.c +++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c @@ -1240,9 +1240,9 @@ static s32 e1000_disable_ulp_lpt_lp(struct e1000_hw *hw, bool force) ew32(H2ME, mac_reg); } - /* Poll up to 300msec for ME to clear ULP_CFG_DONE. */ + /* Poll up to 2.5sec for ME to clear ULP_CFG_DONE. */ while (er32(FWSM) & E1000_FWSM_ULP_CFG_DONE) { - if (i++ == 30) { + if (i++ == 250) { ret_val = -E1000_ERR_PHY; goto out; } -- 2.17.1 I can reproduce this and I can confirm that this patch: https://patchwork.ozlabs.org/patch/1260523/ Fixes this. The x1 carbon 7th and 8th gen are both affected by this and both are very popular laptop models. Not having suspend/resume working on these really is not acceptable. There is still some discussion upstream about the fix, but the fix just extends a timeout so the chance of it causing regressions elsewhere are pretty much 0. So I'm going to add this patch as a downstream patch to the Fedora kernels for now, we can drop it when either this fix or another fix for this issue is merged upstream. Thanks Hans. As a note - Lenovo is communicating with Intel that they need to look into this on their firmware with some urgency - but I appreciate getting this patch in as it is low risk. Hopefully it can be removed again in the future when Intel fix their firmware correctly. I'll update when I hear back from Intel. Mark I have added to the patch to the dist-git for the Fedora kernels for F30 and later, this will get picked up the next time a Fedora kernel build is done. FEDORA-2020-4ef0bcc89c has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-4ef0bcc89c FEDORA-2020-666f3b1ac3 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-666f3b1ac3 FEDORA-2020-cf0857f73a has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-cf0857f73a FEDORA-2020-4ef0bcc89c has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-4ef0bcc89c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-4ef0bcc89c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-666f3b1ac3 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-666f3b1ac3` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-666f3b1ac3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-cf0857f73a has been pushed to the Fedora 30 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-cf0857f73a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-cf0857f73a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-4ef0bcc89c has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. Discussed during the 2020-04-06 blocker review meeting: [0] The decision to delay the classification of this bug as a blocker and to classify it as an "AcceptedFreezeException" was made as there is some support for blocking on suspend issues on widely-used laptop models, but we do not currently have this in the criteria, so we will delay blocker decision to allow proposals. Accepted as an FE issue as a very visible bug on widely-used hardware. [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-04-06/f32-blocker-review.2020-04-06-16.00.txt FEDORA-2020-666f3b1ac3 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2020-73c00eda1c has been pushed to the Fedora 30 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-73c00eda1c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-73c00eda1c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-73c00eda1c has been pushed to the Fedora 30 stable repository. If problem still persists, please make note of it in this bug report. |
Created attachment 1673064 [details] dmesg output for failed suspend Description of problem: after booting the system the first attempt to suspend the system works and subsequent attempts to suspend do not succeed Version-Release number of selected component (if applicable): How reproducible:consistent Steps to Reproduce: 1.boot system clean 2.use suspend from the power off menu item, system suspends 3.wake system and attempt to suspend again by the power menu or systemctl it fails Actual results:system can obnly suspend once after a reboot Expected results:system should suspend each time it is requested Additional info: