Re: e1000e + suspend, 3.9-rc2

From: Jiri Slaby
Date: Mon Jul 15 2013 - 04:25:23 EST

Next message: Jingoo Han: "Re: [PATCH V2] pci: exynos: split into two parts such as Synopsys partand Exynos part"
Previous message: Roger Quadros: "Re: [PATCH 4/6] mfd: omap-usb-host: Put pins in IDLE state on suspend"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Any ideas on this?

On 07/05/2013 10:24 PM, Jiri Slaby wrote:
> On 06/12/2013 11:29 PM, Konstantin Khlebnikov wrote:
>> Jiri Slaby wrote:
>>> On 04/15/2013 05:29 PM, Jiri Slaby wrote:
>>>> On 03/29/2013 07:04 PM, Allan, Bruce W wrote:
>>>>>> -----Original Message-----
>>>>>> From: Jiri Slaby [mailto:jirislaby@xxxxxxxxx] On Behalf Of Jiri Slaby
>>>>>> Sent: Tuesday, March 19, 2013 5:23 AM
>>>>>> To: Konstantin Khlebnikov
>>>>>> Cc: Borislav Petkov; Kirsher, Jeffrey T; Rafael J. Wysocki; Bjorn
>>>>>> Helgaas;
>>>>>> x86@xxxxxxxxxx; lkml; e1000-devel@xxxxxxxxxxxxxxxxxxxxx; Allan,
>>>>>> Bruce W
>>>>>> Subject: Re: e1000e + suspend, 3.9-rc2
>>>>>>
>>>>>>>>> Ok, I can still see the hardware error message when suspending:
>>>>>>>>
>>>>>>>> And with 3.8 plus these:
>>>>>>>> PCI/PM: Clear state_saved during suspend
>>>>>>>> e1000e: fix pci-device enable-counter balance
>>>>>>>> e1000e: fix runtime power management transitions
>>>>>>>> e1000e: fix accessing to suspended device
>>>>>>>>
>>>>>>>> I sometimes see this:
>>>>>>>> pci_pm_suspend():e1000_suspend +0x0/0x10 [e1000e] returns -2
>>>>>>>> dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -2
>>>>>>>> PM: Device 0000:00:19.0 failed to suspend async: error -2
>>>>>>>>
>>>>>>>> Any ideas? Am I missing some patch still?
>>>>>>>
>>>>>>> Try this:
>>>>>>> "PCI: Don't try to disable Bus Master on disconnected PCI devices"
>>>>>>> https://patchwork.kernel.org/patch/2271641/
>>>>>>>
>>>>>>> But I'm not sure, probably it is unrelated because this code works
>>>>>>> only (?)
>>>>>>> during shutdown/kexec sequences.
>>>>>>
>>>>>> I don't think it will help either. -2 here is -E1000_ERR_PHY from
>>>>>> e1000e_write_phy_reg_mdic if I'm looking correctly. I.e. MDIC not
>>>>>> ready
>>>>>> or unlike MDIC_ERROR.
>>>>>>
>>>>>> I think this happened after I put the link down and tried to suspend.
>>>>>>
>>>>>> --
>>>>>> js
>>>>>> suse labs
>>>>>
>>>>> Sorry for not replying sooner, for some reason some of this thread
>>>>> was filtered
>>>>> to my junk folder and I didnât see it until now.
>>>>>
>>>>> Jiri, can you provide the output of 'lspci -s 00:19.0 -n -vv' and
>>>>> confirm the scenario
>>>>> in which the problem occurs? Is this easily reproduced?
>>>>
>>>> Sorry about the late reply, I totally forgot about this. lspci output is
>>>> attached below. The scenario is not rigid as I'm not sure when exactly
>>>> this happens. It looks like I have to use power saving on that device.
>>>> And I don't need to use that device at all. Here is an excerpt from one
>>>> kernel boot modulo e1000e where the error occurred.
>>>>
>>>> e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
>>>> e1000e 0000:00:19.0: setting latency timer to 64
>>>> e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic
>>>> conservative mode
>>>> e1000e 0000:00:19.0: irq 46 for MSI/MSI-X
>>>> e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1)
>>>> 3c:97:0e:35:3d:dd
>>>> e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
>>>> e1000e 0000:00:19.0 eth0: MAC: 10, PHY: 11, PBA No: 1000FF-0FF
>>>> e1000e 0000:00:19.0: irq 46 for MSI/MSI-X
>>>> e1000e 0000:00:19.0: irq 46 for MSI/MSI-X
>>>> e1000e 0000:00:19.0: setting latency timer to 64
>>>> e1000e 0000:00:19.0: irq 46 for MSI/MSI-X
>>>> e1000e 0000:00:19.0: setting latency timer to 64
>>>> e1000e 0000:00:19.0: irq 46 for MSI/MSI-X
>>>> e1000e 0000:00:19.0: irq 46 for MSI/MSI-X
>>>> e1000e 0000:00:19.0: irq 46 for MSI/MSI-X
>>>> e1000e 0000:00:19.0: setting latency timer to 64
>>>> e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
>>>> e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
>>>> e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
>>>> e1000e 0000:00:19.0: setting latency timer to 64
>>>> e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
>>>> e1000e 0000:00:19.0: setting latency timer to 64
>>>> e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
>>>> e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
>>>> e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
>>>> e1000e 0000:00:19.0: setting latency timer to 64
>>>> e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
>>>> pci_pm_suspend(): e1000_suspend+0x0/0x10 [e1000e] returns -2
>>>> pci_pm_suspend(): e1000_suspend+0x0/0x10 [e1000e] returns -2
>>>> pci_pm_suspend(): e1000_suspend+0x0/0x10 [e1000e] returns -2
>>>> pci_pm_suspend(): e1000_suspend+0x0/0x10 [e1000e] returns -2
>>>> pci_pm_suspend(): e1000_suspend+0x0/0x10 [e1000e] returns -2
>>>> pci_pm_suspend(): e1000_suspend+0x0/0x10 [e1000e] returns -2
>>>
>>> This still happens with 3.9.5 ...
>>>
>>> I don't use wired net at all. This usually happens after I enable power
>>> saving.
>>
>> I guess that '-2' is one of 'return -E1000_ERR_PHY',
>> but all that debug messages are omitted by default.
>>
>> Please enable CONFIG_DYNAMIC_DEBUG=y and mount debugfs, after that:
>> # echo module e1000e +p > /sys/kernel/debug/dynamic_debug/control
>> If it would be too verbose you can enable these messages more selective.\
>
> Here we go at last:
>
> e1000e 0000:00:19.0 eth0: Setting page 0x6020
> e1000e 0000:00:19.0 eth0: MDI Write did not complete
> e1000e 0000:00:19.0 eth0: Setting page 0x6020
> e1000e 0000:00:19.0 eth0: MDI Write did not complete
> e1000e 0000:00:19.0 eth0: failed to enable jumbo frame workaround mode
> e1000e 0000:00:19.0 eth0: Setting page 0x0
> e1000e 0000:00:19.0 eth0: MDI Write did not complete
> e1000e 0000:00:19.0 eth0: Setting page 0x0
> e1000e 0000:00:19.0 eth0: MDI Write did not complete
> e1000e 0000:00:19.0 eth0: Setting page 0x6020
> e1000e 0000:00:19.0 eth0: MDI Write did not complete
> e1000e 0000:00:19.0 eth0: Could not set Port Control page
> e1000e 0000:00:19.0 eth0: Setting page 0x6020
> e1000e 0000:00:19.0 eth0: MDI Write did not complete
> e1000e 0000:00:19.0 eth0: Could not set Port Control page
> pci_pm_suspend(): e1000_suspend+0x0/0x10 [e1000e] returns -2
> dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -2
> PM: Device 0000:00:19.0 failed to suspend async: error -2
> PM: Some devices failed to suspend
>
>>>> 00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit
>>>> Network Connection [8086:1502] (rev 04)
>>>> Subsystem: Lenovo Device [17aa:21f3]
>>>> 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 46
>>>> Region 0: Memory at f2500000 (32-bit, non-prefetchable)
>>>> [size=128K]
>>>> Region 1: Memory at f253b000 (32-bit, non-prefetchable)
>>>> [size=4K]
>>>> Region 2: I/O ports at 5080 [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: 00000000fee00398 Data: 0000
>>>> Capabilities: [e0] PCI Advanced Features
>>>> AFCap: TP+ FLR+
>>>> AFCtrl: FLR-
>>>> AFStatus: TP-
>>>> Kernel driver in use: e1000e
>>>>
>>>>
>>>> thanks,
>>>>
>>>
>>>
>>
>
>

--
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Next message: Jingoo Han: "Re: [PATCH V2] pci: exynos: split into two parts such as Synopsys partand Exynos part"
Previous message: Roger Quadros: "Re: [PATCH 4/6] mfd: omap-usb-host: Put pins in IDLE state on suspend"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]