All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kai-Heng Feng <kai.heng.feng@canonical.com>
To: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Cc: jeffrey.t.kirsher@intel.com, intel-wired-lan@lists.osuosl.org,
	linux-kernel@vger.kernel.org, tobias.klausmann@freenet.de
Subject: Re: e1000e regression - 5.4rc1
Date: Mon, 28 Oct 2019 15:07:04 +0800	[thread overview]
Message-ID: <ADFA5FA0-ED36-4313-9CDD-602946FEBA67@canonical.com> (raw)
In-Reply-To: <940da657-a8af-ccde-34ca-7a93fad94567@mni.thm.de>

Hi Tobias,

> On Oct 9, 2019, at 02:28, Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de> wrote:
> 
> Hi,
> 
> On 08.10.19 09:46, Kai-Heng Feng wrote:
>> Hi Tobias,
>> 
>>> On Oct 5, 2019, at 03:52, Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de> wrote:
>>> 
>>> Hello,
>>> 
>>> On 04.10.19 19:36, Kai-Heng Feng wrote:
>>>> Hi Tobias
>>>> 
>>>>> On Oct 4, 2019, at 18:34, Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de> 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>


WARNING: multiple messages have this Message-ID (diff)
From: Kai-Heng Feng <kai.heng.feng@canonical.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] e1000e regression - 5.4rc1
Date: Mon, 28 Oct 2019 15:07:04 +0800	[thread overview]
Message-ID: <ADFA5FA0-ED36-4313-9CDD-602946FEBA67@canonical.com> (raw)
In-Reply-To: <940da657-a8af-ccde-34ca-7a93fad94567@mni.thm.de>

Hi Tobias,

> On Oct 9, 2019, at 02:28, Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de> wrote:
> 
> Hi,
> 
> On 08.10.19 09:46, Kai-Heng Feng wrote:
>> Hi Tobias,
>> 
>>> On Oct 5, 2019, at 03:52, Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de> wrote:
>>> 
>>> Hello,
>>> 
>>> On 04.10.19 19:36, Kai-Heng Feng wrote:
>>>> Hi Tobias
>>>> 
>>>>> On Oct 4, 2019, at 18:34, Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de> 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>


  reply	other threads:[~2019-10-28  7:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-04 10:34 e1000e regression - 5.4rc1 Tobias Klausmann
2019-10-04 10:34 ` [Intel-wired-lan] " Tobias Klausmann
2019-10-04 17:36 ` Kai-Heng Feng
2019-10-04 17:36   ` [Intel-wired-lan] " Kai-Heng Feng
2019-10-04 19:52   ` Tobias Klausmann
2019-10-04 19:52     ` [Intel-wired-lan] " Tobias Klausmann
2019-10-08  7:46     ` Kai-Heng Feng
2019-10-08  7:46       ` [Intel-wired-lan] " Kai-Heng Feng
2019-10-08 18:28       ` Tobias Klausmann
2019-10-08 18:28         ` [Intel-wired-lan] " Tobias Klausmann
2019-10-28  7:07         ` Kai-Heng Feng [this message]
2019-10-28  7:07           ` Kai-Heng Feng
2019-10-31 15:13           ` Tobias Klausmann
2019-10-31 15:13             ` [Intel-wired-lan] " Tobias Klausmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ADFA5FA0-ED36-4313-9CDD-602946FEBA67@canonical.com \
    --to=kai.heng.feng@canonical.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tobias.johannes.klausmann@mni.thm.de \
    --cc=tobias.klausmann@freenet.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.