Bug 202321
| Summary: | [Intel GFX CI] "Generic PHY r8169-200:00: Master/Slave resolution failed, maybe conflicting manual settings?" when suspending | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Martin Peres (martin.peres) |
| Component: | Network | Assignee: | drivers_network (drivers_network) |
| Status: | NEW --- | ||
| Severity: | normal | CC: | hkallweit1, lakshminarayana.vudum |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 5.0.0-rc2 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
Boot log
Kernel logs during the execution of our tests |
||
|
Description
Martin Peres
2019-01-17 12:56:50 UTC
Are you sure regarding USB, I only know RTL8168 family members with PCI interface. Can you provide a full dmesg output? Created attachment 280567 [details]
Boot log
Boot log for the machine.
Created attachment 280569 [details]
Kernel logs during the execution of our tests
(In reply to Heiner Kallweit from comment #1) > Are you sure regarding USB, I only know RTL8168 family members with PCI > interface. > Can you provide a full dmesg output? Sorry, I mis-remembered: 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) I guess I should not trust my memory when caring about so many machines... All the information about the machine can be found here: https://intel-gfx-ci.01.org/hardware/shard-glk6/. The same problem can be seen on shard-glk7 too, which should be identical. So far, it looks like this issue is reproducible roughly every other run of our test suite (which does ~80 suspend/resume cycles per run). Sorry for botching the bug report, I have been context-switching too much today. Thanks for the feedback. The content of the relevant registers could provide a hint what's going on. Could you please apply the following and provide the output of the inserted debug statement if case error occurs again?
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 4f61ebf84..264312137 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1746,6 +1746,7 @@ int genphy_read_status(struct phy_device *phydev)
return adv;
if (lpagb & LPA_1000MSFAIL) {
+ pr_info("master/slave failure: lpagb = 0x%04x adv = 0x%04x\n", lpagb, adv);
if (adv & CTL1000_ENABLE_MASTER)
phydev_err(phydev, "Master/Slave resolution failed, maybe conflicting manual settings?\n");
else
--
2.20.1
(In reply to Heiner Kallweit from comment #5) > Thanks for the feedback. The content of the relevant registers could provide > a hint what's going on. Could you please apply the following and provide the > output of the inserted debug statement if case error occurs again? Sure thing! I'll get this in our testing tree tomorrow :) (In reply to Martin Peres from comment #6) > (In reply to Heiner Kallweit from comment #5) > > Thanks for the feedback. The content of the relevant registers could > provide > > a hint what's going on. Could you please apply the following and provide > the > > output of the inserted debug statement if case error occurs again? > > > Sure thing! I'll get this in our testing tree tomorrow :) Any news here? (In reply to Heiner Kallweit from comment #7) > (In reply to Martin Peres from comment #6) > > (In reply to Heiner Kallweit from comment #5) > > > Thanks for the feedback. The content of the relevant registers could > > provide > > > a hint what's going on. Could you please apply the following and provide > > the > > > output of the inserted debug statement if case error occurs again? > > > > > > Sure thing! I'll get this in our testing tree tomorrow :) > > Any news here? Sorry for the delay, I got the patch applied in our test tree (https://cgit.freedesktop.org/drm-tip/commit/?id=e3a9af5b306dbedfb2a8d84676269ad39473d644), and I'll report back next week with more results :) At least, results should not take long to come, as this has been 100% reproducible on some machines! This issue is not happening anymore, so issue is ready for closure. The CI Bug Log issue associated to this bug has been archived. New failures matching the above filters will not be associated to this bug anymore. |