Hello all,
While testing the 5.4rc1 release, i noticed my Ethernet never coming
fully up, seemingly having a timeout problem. While bisecting this i
landed at the commit dee23594d587386e9fda76732aa5f5a487709510 ("e1000e:
Make speed detection on hotplugging cable more reliable") as the first
bad commit. And indeed just reverting the commit on top of 5.4rc1
resolves the problem. Let me know if you have further questions, or
patches to test!
Greetings,
Tobias
lspci:
00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network
Connection (rev 06)
DeviceName: Onboard LAN
Subsystem: ASUSTeK Computer Inc. P8P67 Deluxe Motherboard
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 56
Region 0: Memory at fbf00000 (32-bit, non-prefetchable) [size=128K]
Region 1: Memory at fbf28000 (32-bit, non-prefetchable) [size=4K]
Region 2: I/O ports at f040 [size=32]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee00698 Data: 0000
Capabilities: [e0] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: e1000e
Kernel modules: e1000e
Hi Tobias
> On Oct 4, 2019, at 18:34, Tobias Klausmann <[email protected]> wrote:
>
> Hello all,
>
> While testing the 5.4rc1 release, i noticed my Ethernet never coming fully up, seemingly having a timeout problem. While bisecting this i landed at the commit dee23594d587386e9fda76732aa5f5a487709510 ("e1000e: Make speed detection on hotplugging cable more reliable") as the first bad commit. And indeed just reverting the commit on top of 5.4rc1 resolves the problem. Let me know if you have further questions, or patches to test!
Is runtime PM enabled (i.e. "power/control" = auto)?
Also please attach full dmesg, thanks!
Kai-Heng
>
> Greetings,
>
> Tobias
>
>
> lspci:
>
> 00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 06)
> DeviceName: Onboard LAN
> Subsystem: ASUSTeK Computer Inc. P8P67 Deluxe Motherboard
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Interrupt: pin A routed to IRQ 56
> Region 0: Memory at fbf00000 (32-bit, non-prefetchable) [size=128K]
> Region 1: Memory at fbf28000 (32-bit, non-prefetchable) [size=4K]
> Region 2: I/O ports at f040 [size=32]
> Capabilities: [c8] Power Management version 2
> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Address: 00000000fee00698 Data: 0000
> Capabilities: [e0] PCI Advanced Features
> AFCap: TP+ FLR+
> AFCtrl: FLR-
> AFStatus: TP-
> Kernel driver in use: e1000e
> Kernel modules: e1000e
>
Hello,
On 04.10.19 19:36, Kai-Heng Feng wrote:
> Hi Tobias
>
>> On Oct 4, 2019, at 18:34, Tobias Klausmann <[email protected]> wrote:
>>
>> Hello all,
>>
>> While testing the 5.4rc1 release, i noticed my Ethernet never coming fully up, seemingly having a timeout problem. While bisecting this i landed at the commit dee23594d587386e9fda76732aa5f5a487709510 ("e1000e: Make speed detection on hotplugging cable more reliable") as the first bad commit. And indeed just reverting the commit on top of 5.4rc1 resolves the problem. Let me know if you have further questions, or patches to test!
> Is runtime PM enabled (i.e. "power/control" = auto)?
Yes it is set to auto.
> Also please attach full dmesg, thanks!
Attached,
Tobias
>
> Kai-Heng
>
>> Greetings,
>>
>> Tobias
>>
>>
>> lspci:
>>
>> 00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 06)
>> DeviceName: Onboard LAN
>> Subsystem: ASUSTeK Computer Inc. P8P67 Deluxe Motherboard
>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>> Latency: 0
>> Interrupt: pin A routed to IRQ 56
>> Region 0: Memory at fbf00000 (32-bit, non-prefetchable) [size=128K]
>> Region 1: Memory at fbf28000 (32-bit, non-prefetchable) [size=4K]
>> Region 2: I/O ports at f040 [size=32]
>> Capabilities: [c8] Power Management version 2
>> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
>> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
>> Address: 00000000fee00698 Data: 0000
>> Capabilities: [e0] PCI Advanced Features
>> AFCap: TP+ FLR+
>> AFCtrl: FLR-
>> AFStatus: TP-
>> Kernel driver in use: e1000e
>> Kernel modules: e1000e
>>
Hi Tobias,
> On Oct 5, 2019, at 03:52, Tobias Klausmann <[email protected]> wrote:
>
> Hello,
>
> On 04.10.19 19:36, Kai-Heng Feng wrote:
>> Hi Tobias
>>
>>> On Oct 4, 2019, at 18:34, Tobias Klausmann <[email protected]> wrote:
>>>
>>> Hello all,
>>>
>>> While testing the 5.4rc1 release, i noticed my Ethernet never coming fully up, seemingly having a timeout problem. While bisecting this i landed at the commit dee23594d587386e9fda76732aa5f5a487709510 ("e1000e: Make speed detection on hotplugging cable more reliable") as the first bad commit. And indeed just reverting the commit on top of 5.4rc1 resolves the problem. Let me know if you have further questions, or patches to test!
>> Is runtime PM enabled (i.e. "power/control" = auto)?
>
>
> Yes it is set to auto.
Is something like TLP or `powertop --auto-tune` is in use?
Do you still see the issue when "power/control" keeps at "on"?
Kai-Heng
>
>
>> Also please attach full dmesg, thanks!
>
> Attached,
>
> Tobias
>
>>
>> Kai-Heng
>>
>>> Greetings,
>>>
>>> Tobias
>>>
>>>
>>> lspci:
>>>
>>> 00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 06)
>>> DeviceName: Onboard LAN
>>> Subsystem: ASUSTeK Computer Inc. P8P67 Deluxe Motherboard
>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>>> Latency: 0
>>> Interrupt: pin A routed to IRQ 56
>>> Region 0: Memory at fbf00000 (32-bit, non-prefetchable) [size=128K]
>>> Region 1: Memory at fbf28000 (32-bit, non-prefetchable) [size=4K]
>>> Region 2: I/O ports at f040 [size=32]
>>> Capabilities: [c8] Power Management version 2
>>> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
>>> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
>>> Address: 00000000fee00698 Data: 0000
>>> Capabilities: [e0] PCI Advanced Features
>>> AFCap: TP+ FLR+
>>> AFCtrl: FLR-
>>> AFStatus: TP-
>>> Kernel driver in use: e1000e
>>> Kernel modules: e1000e
>>>
> <dmesg.txt>
Hi,
On 08.10.19 09:46, Kai-Heng Feng wrote:
> Hi Tobias,
>
>> On Oct 5, 2019, at 03:52, Tobias Klausmann <[email protected]> wrote:
>>
>> Hello,
>>
>> On 04.10.19 19:36, Kai-Heng Feng wrote:
>>> Hi Tobias
>>>
>>>> On Oct 4, 2019, at 18:34, Tobias Klausmann <[email protected]> wrote:
>>>>
>>>> Hello all,
>>>>
>>>> While testing the 5.4rc1 release, i noticed my Ethernet never coming fully up, seemingly having a timeout problem. While bisecting this i landed at the commit dee23594d587386e9fda76732aa5f5a487709510 ("e1000e: Make speed detection on hotplugging cable more reliable") as the first bad commit. And indeed just reverting the commit on top of 5.4rc1 resolves the problem. Let me know if you have further questions, or patches to test!
>>> Is runtime PM enabled (i.e. "power/control" = auto)?
>>
>> Yes it is set to auto.
> Is something like TLP or `powertop --auto-tune` is in use?
>
> Do you still see the issue when "power/control" keeps at "on"?
With "power/control" set to "on" it does still cycle between up and
down. But yes i have upower and powerdevil running. After killing them
the connection comes up with "power/control" set to "on", yet not with
"auto".
Greetings,
Tobias
>
> Kai-Heng
>
>>
>>> Also please attach full dmesg, thanks!
>> Attached,
>>
>> Tobias
>>
>>> Kai-Heng
>>>
>>>> Greetings,
>>>>
>>>> Tobias
>>>>
>>>>
>>>> lspci:
>>>>
>>>> 00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 06)
>>>> DeviceName: Onboard LAN
>>>> Subsystem: ASUSTeK Computer Inc. P8P67 Deluxe Motherboard
>>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
>>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>> Latency: 0
>>>> Interrupt: pin A routed to IRQ 56
>>>> Region 0: Memory at fbf00000 (32-bit, non-prefetchable) [size=128K]
>>>> Region 1: Memory at fbf28000 (32-bit, non-prefetchable) [size=4K]
>>>> Region 2: I/O ports at f040 [size=32]
>>>> Capabilities: [c8] Power Management version 2
>>>> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>>>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
>>>> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
>>>> Address: 00000000fee00698 Data: 0000
>>>> Capabilities: [e0] PCI Advanced Features
>>>> AFCap: TP+ FLR+
>>>> AFCtrl: FLR-
>>>> AFStatus: TP-
>>>> Kernel driver in use: e1000e
>>>> Kernel modules: e1000e
>>>>
>> <dmesg.txt>
Hi Tobias,
> On Oct 9, 2019, at 02:28, Tobias Klausmann <[email protected]> wrote:
>
> Hi,
>
> On 08.10.19 09:46, Kai-Heng Feng wrote:
>> Hi Tobias,
>>
>>> On Oct 5, 2019, at 03:52, Tobias Klausmann <[email protected]> wrote:
>>>
>>> Hello,
>>>
>>> On 04.10.19 19:36, Kai-Heng Feng wrote:
>>>> Hi Tobias
>>>>
>>>>> On Oct 4, 2019, at 18:34, Tobias Klausmann <[email protected]> wrote:
>>>>>
>>>>> Hello all,
>>>>>
>>>>> While testing the 5.4rc1 release, i noticed my Ethernet never coming fully up, seemingly having a timeout problem. While bisecting this i landed at the commit dee23594d587386e9fda76732aa5f5a487709510 ("e1000e: Make speed detection on hotplugging cable more reliable") as the first bad commit. And indeed just reverting the commit on top of 5.4rc1 resolves the problem. Let me know if you have further questions, or patches to test!
>>>> Is runtime PM enabled (i.e. "power/control" = auto)?
>>>
>>> Yes it is set to auto.
>> Is something like TLP or `powertop --auto-tune` is in use?
>>
>> Do you still see the issue when "power/control" keeps at "on"?
>
>
> With "power/control" set to "on" it does still cycle between up and down. But yes i have upower and powerdevil running. After killing them the connection comes up with "power/control" set to "on", yet not with "auto".
Can you please give this branch a try:
https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git/log/?h=dev-queue
Kai-Heng
>
>
> Greetings,
>
> Tobias
>
>
>>
>> Kai-Heng
>>
>>>
>>>> Also please attach full dmesg, thanks!
>>> Attached,
>>>
>>> Tobias
>>>
>>>> Kai-Heng
>>>>
>>>>> Greetings,
>>>>>
>>>>> Tobias
>>>>>
>>>>>
>>>>> lspci:
>>>>>
>>>>> 00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 06)
>>>>> DeviceName: Onboard LAN
>>>>> Subsystem: ASUSTeK Computer Inc. P8P67 Deluxe Motherboard
>>>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
>>>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>>> Latency: 0
>>>>> Interrupt: pin A routed to IRQ 56
>>>>> Region 0: Memory at fbf00000 (32-bit, non-prefetchable) [size=128K]
>>>>> Region 1: Memory at fbf28000 (32-bit, non-prefetchable) [size=4K]
>>>>> Region 2: I/O ports at f040 [size=32]
>>>>> Capabilities: [c8] Power Management version 2
>>>>> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>>>>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
>>>>> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
>>>>> Address: 00000000fee00698 Data: 0000
>>>>> Capabilities: [e0] PCI Advanced Features
>>>>> AFCap: TP+ FLR+
>>>>> AFCtrl: FLR-
>>>>> AFStatus: TP-
>>>>> Kernel driver in use: e1000e
>>>>> Kernel modules: e1000e
>>>>>
>>> <dmesg.txt>
Hi,
On 28.10.19 08:07, Kai-Heng Feng wrote:
> Hi Tobias,
>
>> On Oct 9, 2019, at 02:28, Tobias Klausmann <[email protected]> wrote:
>>
>> Hi,
>>
>> On 08.10.19 09:46, Kai-Heng Feng wrote:
>>> Hi Tobias,
>>>
>>>> On Oct 5, 2019, at 03:52, Tobias Klausmann <[email protected]> wrote:
>>>>
>>>> Hello,
>>>>
>>>> On 04.10.19 19:36, Kai-Heng Feng wrote:
>>>>> Hi Tobias
>>>>>
>>>>>> On Oct 4, 2019, at 18:34, Tobias Klausmann <[email protected]> wrote:
>>>>>>
>>>>>> Hello all,
>>>>>>
>>>>>> While testing the 5.4rc1 release, i noticed my Ethernet never coming fully up, seemingly having a timeout problem. While bisecting this i landed at the commit dee23594d587386e9fda76732aa5f5a487709510 ("e1000e: Make speed detection on hotplugging cable more reliable") as the first bad commit. And indeed just reverting the commit on top of 5.4rc1 resolves the problem. Let me know if you have further questions, or patches to test!
>>>>> Is runtime PM enabled (i.e. "power/control" = auto)?
>>>> Yes it is set to auto.
>>> Is something like TLP or `powertop --auto-tune` is in use?
>>>
>>> Do you still see the issue when "power/control" keeps at "on"?
>>
>> With "power/control" set to "on" it does still cycle between up and down. But yes i have upower and powerdevil running. After killing them the connection comes up with "power/control" set to "on", yet not with "auto".
> Can you please give this branch a try:
> https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git/log/?h=dev-queue
Compiled and tested as is (not having set /power/control) the up and
down cycle is still persistent.
Greetings,
Tobias
>
> Kai-Heng
>
>>
>> Greetings,
>>
>> Tobias
>>
>>
>>> Kai-Heng
>>>
>>>>> Also please attach full dmesg, thanks!
>>>> Attached,
>>>>
>>>> Tobias
>>>>
>>>>> Kai-Heng
>>>>>
>>>>>> Greetings,
>>>>>>
>>>>>> Tobias
>>>>>>
>>>>>>
>>>>>> lspci:
>>>>>>
>>>>>> 00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 06)
>>>>>> DeviceName: Onboard LAN
>>>>>> Subsystem: ASUSTeK Computer Inc. P8P67 Deluxe Motherboard
>>>>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
>>>>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>>>> Latency: 0
>>>>>> Interrupt: pin A routed to IRQ 56
>>>>>> Region 0: Memory at fbf00000 (32-bit, non-prefetchable) [size=128K]
>>>>>> Region 1: Memory at fbf28000 (32-bit, non-prefetchable) [size=4K]
>>>>>> Region 2: I/O ports at f040 [size=32]
>>>>>> Capabilities: [c8] Power Management version 2
>>>>>> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>>>>>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
>>>>>> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
>>>>>> Address: 00000000fee00698 Data: 0000
>>>>>> Capabilities: [e0] PCI Advanced Features
>>>>>> AFCap: TP+ FLR+
>>>>>> AFCtrl: FLR-
>>>>>> AFStatus: TP-
>>>>>> Kernel driver in use: e1000e
>>>>>> Kernel modules: e1000e
>>>>>>
>>>> <dmesg.txt>