Bug 201977 - [HP 847B i5-8300H ]e1000e took too much time in e1000_init_phy_workarounds_pchlan() during resume from suspend to idle
Summary: [HP 847B i5-8300H ]e1000e took too much time in e1000_init_phy_workarounds_pc...
Status: ASSIGNED
Alias: None
Product: Drivers
Classification: Unclassified
Component: Network (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: Sasha Neftin
URL:
Keywords:
Depends on:
Blocks: 178231
  Show dependency tree
 
Reported: 2018-12-12 13:59 UTC by Chen Yu
Modified: 2023-07-26 14:36 UTC (History)
6 users (show)

See Also:
Kernel Version: 4.20-rc2
Subsystem:
Regression: No
Bisected commit-id:


Attachments
pm-graph data of suspend to idle (504.21 KB, text/html)
2018-12-12 13:59 UTC, Chen Yu
Details
issue.def (486 bytes, text/plain)
2020-05-13 18:32 UTC, Todd Brandt
Details
issue.def (486 bytes, text/plain)
2023-07-26 14:36 UTC, Todd Brandt
Details

Description Chen Yu 2018-12-12 13:59:51 UTC
Created attachment 279971 [details]
pm-graph data of suspend to idle

On this coffelake platform, it took almost 1 second for the e1000e driver to
resume back from suspend to idle. According to the pm-graph tracking data, most of the time in e1000e were spent on e1000_init_phy_workarounds_pchlan(), since there are a lot of usleep_range(10000, 20000) invoked during this stage(although there's no network cable connected at the moment).
According to the log description, this workaround was introduced in 
commit cb17aab916b0467faecf241c9b3b396b6da045d9
    e1000e: PHY initialization flow changes for 82577/8/9

Is this inevitable for 82577/8/9 PHY?
Also find attached the pm-graph html figure for reference.
Comment 1 Jeff Kirsher 2019-01-11 18:34:18 UTC
Yes, the "e1000_init_phy_workarounds_pchlan" is required to all our 1G client LAN controllers started from LynxPoint systems, where is external PHY access required.

We did not specifically test with the Coffee Lake platform, mainly because we do not have one available to us for testing.

We did double check with a Cannon Lake system, but did not see the long delay in the resume that you saw.  Our validation saw the entire resume time was 840.690 ms on that platform, and the e1000e driver was taking about 300 ms in total to resume.

On a side note, Bruce Allan no longer maintains e1000e.  Sasha Neftin is now the maintainer of e1000e.
Comment 2 Len Brown 2019-01-17 01:19:28 UTC
Even if this were 300ms instead of over 1,000ms, that still counts as broken.
Comment 3 Todd Brandt 2020-05-13 18:32:31 UTC
Created attachment 289127 [details]
issue.def
Comment 4 Todd Brandt 2023-07-26 14:36:27 UTC
Created attachment 304702 [details]
issue.def

Note You need to log in before you can comment on or make changes to this bug.