eth0 high power usage when not plugged in. Thinkpad T430s

paraffin · 2014-04-04 18:22:52

I've been getting Powertop readings that say my eth0 device is constantly using about 5W of power with nothing plugged into it, which is easily half of my total discharge rate when mostly idle.

The obvious fix I tried was using # ifconfig eth0 down, which does lead to eth0 no longer showing up as using power in Powertop, but the total discharge rate does not change. I have read online that powertop power usage readings shouldn't necessarily be trusted, but its numbers for individual power draws do add up to the battery-reported discharge rate when eth0 is showing. I have run powertop --calibrate with no change in this behavior.

A very possibly related issue is that very occasionally, usually when I've been using the Ethernet port, the dhcpcd process CPU usage will shoot up to 100% and stay there whenever the Ethernet is unplugged. I use WICD as a network manager.

I have all of the 'Tunables' Powertop listed turned on.

Also potentially relevant, I do have TLP installed, along with dkms-acpi_call-git and tpacpi-bat for battery thresholding, though currently I'm having hopefully unrelated issues with that which I haven't looked into very deeply yet. TLP does not seem to have any controls for eth0, only wireless interfaces.

Any ideas what could be causing this, or troubleshooting methods?

Thanks.

EDIT: In the description column, powertop says I'm using the e1000e driver for the interface.

Last edited by paraffin (2014-04-04 18:36:17)

Fackamato · 2014-04-04 23:28:25

modinfo e1000e

vermagic:       3.13.8-1-ARCH SMP preempt mod_unload modversions 
parm:           debug:Debug level (0=none,...,16=all) (int)
parm:           copybreak:Maximum size of packet that is copied to a new buffer on receive (uint)
parm:           TxIntDelay:Transmit Interrupt Delay (array of int)
parm:           TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of int)
parm:           RxIntDelay:Receive Interrupt Delay (array of int)
parm:           RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int)
parm:           InterruptThrottleRate:Interrupt Throttling Rate (array of int)
parm:           IntMode:Interrupt Mode (array of int)
parm:           SmartPowerDownEnable:Enable PHY smart power down (array of int)
parm:           KumeranLockLoss:Enable Kumeran lock loss workaround (array of int)
parm:           WriteProtectNVM:Write-protect NVM [WARNING: disabling this can lead to corrupted NVM] (array of int)
parm:           CrcStripping:Enable CRC Stripping, disable if your BMC needs the CRC (array of int)

You could try the debug option and see if the module is doing something it shouldn't. There's also SmartPowerDownEnable.

paraffin · 2014-04-04 23:30:21

Thanks, I'll check those out.

paraffin · 2014-04-05 00:23:55

$ modinfo e1000e                                                                                                                         [19:10:50]
filename:       /lib/modules/3.13.6-1-ARCH/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko.gz
version:        2.3.2-k
license:        GPL
description:    Intel(R) PRO/1000 Network Driver
author:         Intel Corporation, <linux.nics@intel.com>
srcversion:     FAFC167239309C03F11F440
alias:          pci:v00008086d000015A3sv*sd*bc*sc*i*
alias:          pci:v00008086d000015A2sv*sd*bc*sc*i*
alias:          pci:v00008086d000015A1sv*sd*bc*sc*i*
alias:          pci:v00008086d000015A0sv*sd*bc*sc*i*
alias:          pci:v00008086d00001559sv*sd*bc*sc*i*
alias:          pci:v00008086d0000155Asv*sd*bc*sc*i*
alias:          pci:v00008086d0000153Bsv*sd*bc*sc*i*
alias:          pci:v00008086d0000153Asv*sd*bc*sc*i*
alias:          pci:v00008086d00001503sv*sd*bc*sc*i*
alias:          pci:v00008086d00001502sv*sd*bc*sc*i*
alias:          pci:v00008086d000010F0sv*sd*bc*sc*i*
alias:          pci:v00008086d000010EFsv*sd*bc*sc*i*
alias:          pci:v00008086d000010EBsv*sd*bc*sc*i*
alias:          pci:v00008086d000010EAsv*sd*bc*sc*i*
alias:          pci:v00008086d00001525sv*sd*bc*sc*i*
alias:          pci:v00008086d000010DFsv*sd*bc*sc*i*
alias:          pci:v00008086d000010DEsv*sd*bc*sc*i*
alias:          pci:v00008086d000010CEsv*sd*bc*sc*i*
alias:          pci:v00008086d000010CDsv*sd*bc*sc*i*
alias:          pci:v00008086d000010CCsv*sd*bc*sc*i*
alias:          pci:v00008086d000010CBsv*sd*bc*sc*i*
alias:          pci:v00008086d000010F5sv*sd*bc*sc*i*
alias:          pci:v00008086d000010BFsv*sd*bc*sc*i*
alias:          pci:v00008086d000010E5sv*sd*bc*sc*i*
alias:          pci:v00008086d0000294Csv*sd*bc*sc*i*
alias:          pci:v00008086d000010BDsv*sd*bc*sc*i*
alias:          pci:v00008086d000010C3sv*sd*bc*sc*i*
alias:          pci:v00008086d000010C2sv*sd*bc*sc*i*
alias:          pci:v00008086d000010C0sv*sd*bc*sc*i*
alias:          pci:v00008086d00001501sv*sd*bc*sc*i*
alias:          pci:v00008086d00001049sv*sd*bc*sc*i*
alias:          pci:v00008086d0000104Dsv*sd*bc*sc*i*
alias:          pci:v00008086d0000104Bsv*sd*bc*sc*i*
alias:          pci:v00008086d0000104Asv*sd*bc*sc*i*
alias:          pci:v00008086d000010C4sv*sd*bc*sc*i*
alias:          pci:v00008086d000010C5sv*sd*bc*sc*i*
alias:          pci:v00008086d0000104Csv*sd*bc*sc*i*
alias:          pci:v00008086d000010BBsv*sd*bc*sc*i*
alias:          pci:v00008086d00001098sv*sd*bc*sc*i*
alias:          pci:v00008086d000010BAsv*sd*bc*sc*i*
alias:          pci:v00008086d00001096sv*sd*bc*sc*i*
alias:          pci:v00008086d0000150Csv*sd*bc*sc*i*
alias:          pci:v00008086d000010F6sv*sd*bc*sc*i*
alias:          pci:v00008086d000010D3sv*sd*bc*sc*i*
alias:          pci:v00008086d0000109Asv*sd*bc*sc*i*
alias:          pci:v00008086d0000108Csv*sd*bc*sc*i*
alias:          pci:v00008086d0000108Bsv*sd*bc*sc*i*
alias:          pci:v00008086d0000107Fsv*sd*bc*sc*i*
alias:          pci:v00008086d0000107Esv*sd*bc*sc*i*
alias:          pci:v00008086d0000107Dsv*sd*bc*sc*i*
alias:          pci:v00008086d000010B9sv*sd*bc*sc*i*
alias:          pci:v00008086d000010D5sv*sd*bc*sc*i*
alias:          pci:v00008086d000010DAsv*sd*bc*sc*i*
alias:          pci:v00008086d000010D9sv*sd*bc*sc*i*
alias:          pci:v00008086d00001060sv*sd*bc*sc*i*
alias:          pci:v00008086d000010A5sv*sd*bc*sc*i*
alias:          pci:v00008086d000010BCsv*sd*bc*sc*i*
alias:          pci:v00008086d000010A4sv*sd*bc*sc*i*
alias:          pci:v00008086d0000105Fsv*sd*bc*sc*i*
alias:          pci:v00008086d0000105Esv*sd*bc*sc*i*
depends:        ptp
intree:         Y
vermagic:       3.13.6-1-ARCH SMP preempt mod_unload modversions 
parm:           debug:Debug level (0=none,...,16=all) (int)
parm:           copybreak:Maximum size of packet that is copied to a new buffer on receive (uint)
parm:           TxIntDelay:Transmit Interrupt Delay (array of int)
parm:           TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of int)
parm:           RxIntDelay:Receive Interrupt Delay (array of int)
parm:           RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int)
parm:           InterruptThrottleRate:Interrupt Throttling Rate (array of int)
parm:           IntMode:Interrupt Mode (array of int)
parm:           SmartPowerDownEnable:Enable PHY smart power down (array of int)
parm:           KumeranLockLoss:Enable Kumeran lock loss workaround (array of int)
parm:           WriteProtectNVM:Write-protect NVM [WARNING: disabling this can lead to corrupted NVM] (array of int)
parm:           CrcStripping:Enable CRC Stripping, disable if your BMC needs the CRC (array of int)

This is my output. I don't really know what to make of it. Is there a good reason for it to have all those aliases? Might that be something to do with it?

Also, does PHY mean physical device?

Fackamato · 2014-04-05 00:34:19

No I meant for you to try those module options to see if they help out in your situation.

paraffin · 2014-04-05 00:37:11

I tried SmartPowerDownEnable and it didn't seem to have an effect. However, I'm not sure what the documentation means by 'lower power states' when it says

SmartPowerDownEnable
--------------------
Valid Range: 0-1
Default Value:  0 (disabled)

Allows Phy to turn off in lower power states. The user can turn off
this parameter in supported chipsets.

http://downloadmirror.intel.com/9180/eng/README.txt

Now I'll give the debug a go...

paraffin · 2014-04-05 00:44:03

This is the dmesg output when I do # ifconfig eth0 down and then up with debug on 16... Not super illuminating. Do I need to reboot after the # modprobe e1000e debug=16?

[19204.183288] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
[19216.870650] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
[19216.973392] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
[19216.974151] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

Fackamato · 2014-04-05 00:44:17

paraffin wrote:

I tried SmartPowerDownEnable and it didn't seem to have an effect. However, I'm not sure what the documentation means by 'lower power states' when it says
SmartPowerDownEnable
--------------------
Valid Range: 0-1
Default Value:  0 (disabled)

Allows Phy to turn off in lower power states. The user can turn off
this parameter in supported chipsets.
http://downloadmirror.intel.com/9180/eng/README.txt
Now I'll give the debug a go...

Did you manually try to activate this power state (by echo in /sys or /proc)

paraffin · 2014-04-05 00:48:47

No. I don't really have an idea of what file to be looking for or what I'd echo to it.

Sorry, I'm sort of helpless with this more advanced driver/hardware stuff and I don't know where to find the info I need.

paraffin · 2014-04-05 01:08:37

I don't know if this helps, but here's a verbose lspci output:

00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04)
        Subsystem: Lenovo Device 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 43
        Region 0: Memory at f3500000 (32-bit, non-prefetchable) [size=128K]
        Region 1: Memory at f353a000 (32-bit, non-prefetchable) [size=4K]
        Region 2: I/O ports at 6060 [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: 00000000fee0f00c  Data: 4154
        Capabilities: [e0] PCI Advanced Features
                AFCap: TP+ FLR+
                AFCtrl: FLR-
                AFStatus: TP-
        Kernel driver in use: e1000e
        Kernel modules: e1000e

That seems to say that it's in it's lowest power state (D0), but the power usage in power top is still there.

Fackamato · 2014-04-05 01:50:33

You have to unload the module before loading it again with the module options (unless that's what you did)

Also see https://lists.01.org/pipermail/powertop … 01219.html

paraffin · 2014-04-05 02:14:47

I did not know I had to unload it first.

Here's what I get if I unload and reload, then check dmesg. The actual tail output was of course 10 lines long, so I pasted some more of the full output, starting with the results of a previous modprobe.

Between each CLI entry I checked the battery discharge rate. It remained constant.

aconway:~/ $ sudo modprobe -r e1000e
aconway:~/ $ sudo ifconfig eth0 up
eth0: ERROR while getting interface flags: No such device
aconway:~/ $ sudo modprobe e1000e debug=16 SmartPowerDownEnable=1
aconway:~/ $ sudo ifconfig eth0 up
aconway:~/ $ dmesg | tail
[24044.482442] e1000e 0000:00:19.0 eth0: registered PHC clock
[24044.482447] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 3c:97:0e:61:ea:a8
[24044.482449] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
[24044.482513] e1000e 0000:00:19.0 eth0: MAC: 10, PHY: 11, PBA No: 1000FF-0FF
[24072.318131] e1000e 0000:00:19.0 eth0: removed PHC
[24103.898812] pps_core: LinuxPPS API ver. 1 registered
[24103.898817] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[24103.899435] PTP clock support registered
[24103.903409] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
[24103.903412] e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
[24103.903656] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[24103.903659] e1000e 0000:00:19.0: PHY Smart Power Down Enabled
[24103.903687] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
[24104.144583] e1000e 0000:00:19.0 eth0: registered PHC clock
[24104.144588] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 3c:97:0e:61:ea:a8
[24104.144590] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
[24104.144641] e1000e 0000:00:19.0 eth0: MAC: 10, PHY: 11, PBA No: 1000FF-0FF
[24109.572811] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
[24109.675917] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
[24109.676214] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

Thanks for that link, that's the first indication I've seen that I'm not the only person with this problem Unfortunately it doesn't seem they came to any conclusions.

Do you think it would be worth it to try to move to linux-lts? I've been considering that since random kernel releases will leave my machine unbootable until I pop in my Arch USB stick, chroot and downgrade the kernel to a working version, which seems to be a somewhat common issue with this line of ThinkPads.

paraffin · 2014-04-05 02:36:35

I think I found the HW device in /sys/ though, the full path being /sys/bus/pci/devices/0000:00:19.0/. I can't figure out a way to echo "off" to power/control, which currently reads 'on'. But here's what the directory contains:

aconway:~/ $ ls /sys/bus/pci/devices/0000:00:19.0/ 
broken_parity_status  consistent_dma_mask_bits  dma_mask_bits  firmware_node  local_cpus  net        ptp     reset      resource1  subsystem_device  vendor
class                 d3cold_allowed            driver         irq            modalias    numa_node  remove  resource   resource2  subsystem_vendor
config                device                    enabled        local_cpulist  msi_bus     power      rescan  resource0  subsystem  uevent
aconway:~/ $ ls /sys/bus/pci/devices/0000:00:19.0/power
async                 runtime_active_kids  runtime_status          wakeup              wakeup_active_count  wakeup_last_time_ms           wakeup_total_time_ms
autosuspend_delay_ms  runtime_active_time  runtime_suspended_time  wakeup_abort_count  wakeup_count         wakeup_max_time_ms
control               runtime_enabled      runtime_usage           wakeup_active       wakeup_expire_count  wakeup_prevent_sleep_time_ms

linrunner · 2014-04-05 11:02:03

Hi,

paraffin wrote:

I've been getting Powertop readings that say my eth0 device is constantly using about 5W of power with nothing plugged into it, which is easily half of my total discharge rate when mostly idle.

powertop is telling you bullshit and you should definitely ignore the component related values. It is impossible to measure single component's power consumption, instead powertop calculates "estimations" that are terribly wrong.

Nevertheless you should investigate your observation about dhcpd using 100% cpu.

Last edited by linrunner (2014-04-05 11:10:35)

ewaller · 2014-04-05 15:23:17

I tend to agree with linrunner. 5 W is huge and is way out of line with what I would expect a NIC with PHY to possibly dissipate -- By about an order of magnitude.

WonderWoofy · 2014-04-05 15:51:44

I have noticed though that with wicd it just puts all devices up, which seem unnecessary to me. I agree that the NIC probably isn't using anywhere even remotely close to 5W (my whole machine reports ~7W), but it does seem silly to have the wired ethernet interface up even if it is not in use...

Arch Linux

#1 2014-04-04 18:22:52

eth0 high power usage when not plugged in. Thinkpad T430s

#2 2014-04-04 23:28:25

Re: eth0 high power usage when not plugged in. Thinkpad T430s

#3 2014-04-04 23:30:21

Re: eth0 high power usage when not plugged in. Thinkpad T430s

#4 2014-04-05 00:23:55

Re: eth0 high power usage when not plugged in. Thinkpad T430s

#5 2014-04-05 00:34:19

Re: eth0 high power usage when not plugged in. Thinkpad T430s

#6 2014-04-05 00:37:11

Re: eth0 high power usage when not plugged in. Thinkpad T430s

#7 2014-04-05 00:44:03

Re: eth0 high power usage when not plugged in. Thinkpad T430s

#8 2014-04-05 00:44:17

Re: eth0 high power usage when not plugged in. Thinkpad T430s

#9 2014-04-05 00:48:47

Re: eth0 high power usage when not plugged in. Thinkpad T430s

#10 2014-04-05 01:08:37

Re: eth0 high power usage when not plugged in. Thinkpad T430s

#11 2014-04-05 01:50:33

Re: eth0 high power usage when not plugged in. Thinkpad T430s

#12 2014-04-05 02:14:47

Re: eth0 high power usage when not plugged in. Thinkpad T430s

#13 2014-04-05 02:36:35

Re: eth0 high power usage when not plugged in. Thinkpad T430s

#14 2014-04-05 11:02:03

Re: eth0 high power usage when not plugged in. Thinkpad T430s

#15 2014-04-05 15:23:17

Re: eth0 high power usage when not plugged in. Thinkpad T430s

#16 2014-04-05 15:51:44

Re: eth0 high power usage when not plugged in. Thinkpad T430s

Board footer