Bug 201977
| Summary: | [HP 847B i5-8300H ]e1000e took too much time in e1000_init_phy_workarounds_pchlan() during resume from suspend to idle | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Chen Yu (yu.c.chen) |
| Component: | Network | Assignee: | Sasha Neftin (sasha.neftin) |
| Status: | ASSIGNED --- | ||
| Severity: | normal | CC: | jeffrey.t.kirsher, lenb, rui.zhang, sasha.neftin, tebrandt, todd.e.brandt |
| Priority: | P1 | ||
| Hardware: | Intel | ||
| OS: | Linux | ||
| Kernel Version: | 4.20-rc2 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 178231 | ||
| Attachments: |
pm-graph data of suspend to idle
issue.def issue.def |
||
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. Even if this were 300ms instead of over 1,000ms, that still counts as broken. Created attachment 289127 [details]
issue.def
Created attachment 304702 [details]
issue.def
|
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.