Messages in this thread | | | Date | Fri, 05 Jul 2013 22:24:28 +0200 | From | Jiri Slaby <> | Subject | Re: e1000e + suspend, 3.9-rc2 |
| |
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@gmail.com] 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@kernel.org; lkml; e1000-devel@lists.sourceforge.net; 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |