[Pkg-acpi-devel] Bug#728692: acpi-support breaks Intel I210 Gigabit by enabling power saving

Martin von Wittich martin.von.wittich at iserv.eu
Mon Nov 4 09:47:58 UTC 2013


Package: acpi-support
Version: 0.140-5
Severity: normal

We recently received new servers with Asus P9D-I mainboards. These mainboards
have two Intel I210 NICs onboard:

root at debian:~# lspci
00:00.0 Host bridge: Intel Corporation Haswell DRAM Controller (rev 06)
00:14.0 USB controller: Intel Corporation Lynx Point USB xHCI Host Controller (rev 05)
00:1a.0 USB controller: Intel Corporation Lynx Point USB Enhanced Host Controller #2 (rev 05)
00:1c.0 PCI bridge: Intel Corporation Lynx Point PCI Express Root Port #1 (rev d5)
00:1c.1 PCI bridge: Intel Corporation Lynx Point PCI Express Root Port #2 (rev d5)
00:1c.2 PCI bridge: Intel Corporation Lynx Point PCI Express Root Port #3 (rev d5)
00:1d.0 USB controller: Intel Corporation Lynx Point USB Enhanced Host Controller #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation Lynx Point LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation Lynx Point 6-port SATA Controller 1 [AHCI mode] (rev 05)
00:1f.3 SMBus: Intel Corporation Lynx Point SMBus Controller (rev 05)
01:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)
02:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)
03:00.0 PCI bridge: ASPEED Technology, Inc. AST1150 PCI-to-PCI Bridge (rev 02)
04:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics Family (rev 21)

Both NICs are connected to a switch. Unfortunately, these NICs had weird issues
whenever we installed our Debian-based system (essentially Debian wheezy, but
with a lot of packages preinstalled). Sometimes both NICs were affected,
sometimes only one (usually eth1). They would show up in ifconfig:

root at debian:~# ifconfig -a
eth0      Link encap:Ethernet  HWaddr ac:22:0b:8b:30:a7  
          inet addr:10.255.236.255  Bcast:10.255.255.255  Mask:255.0.0.0
          inet6 addr: fe80::ae22:bff:fe8b:30a7/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1492  Metric:1
          RX packets:1324 errors:0 dropped:0 overruns:0 frame:0
          TX packets:168 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:107124 (104.6 KiB)  TX bytes:25199 (24.6 KiB)
          Memory:dfe00000-dfe80000 

eth1      Link encap:Ethernet  HWaddr ac:22:0b:8b:30:a8  
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:dfd00000-dfd80000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

But enabling the affected NIC or accessing it with ethtool would fail:

root at debian:~# ifconfig eth1 up
SIOCSIFFLAGS: No such device

root at debian:~# dhclient eth1
RTNETLINK answers: No such device

root at debian:~# ethtool eth1
Settings for eth1:
Cannot get device settings: No such device
Cannot get wake-on-lan settings: No such device
Cannot get message level: No such device
Cannot get link status: No such device
No data available


After we noticed that a clean Wheezy installation was not affected, we looked
for differences between the clean installation and our system, and we tracked
the issue down to acpi-support. The following command from the init script:

root at debian:~# grep -m1 on_ac_power /etc/init.d/acpi-support
    on_ac_power || /etc/acpi/power.sh true

behaves unexpectedly because on_ac_power returns 255 on these servers:

root at debian:~# on_ac_power ; echo $?
255

It therefore believes that the server is on battery power, and enables power
saving. This in turn modifies the NICs - I believe the relevant section from
/var/log/pm-powersave.log is this one:

Running hook /usr/lib/pm-utils/power.d/pci_devices true:
Setting Host Bridge 0000:00:00.0 to auto
Setting Ethernet device 0000:01:00.0 to auto
Setting Ethernet device 0000:02:00.0 to auto

This seems to be the cause for our issue. We will resolve the issue by
replacing acpi-support with acpi-support-base in our system dependencies, but I
filed this bug anyway because this issue was very hard to track down and the
information could be useful for others.

-- System Information:
Debian Release: 7.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.10-0.bpo.3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages acpi-support depends on:
ii  acpi-fakekey       0.140-5
ii  acpi-support-base  0.140-5
ii  acpid              1:2.0.16-1+deb7u1
ii  lsb-base           4.1+Debian8+deb7u1
ii  pm-utils           1.4.1-9
ii  x11-xserver-utils  7.7~3

Versions of packages acpi-support recommends:
ii  dbus          1.6.8-1+deb7u1
ii  radeontool    1.6.2-1.1
ii  vbetool       1.1-2
ii  xscreensaver  5.15-3

Versions of packages acpi-support suggests:
pn  rfkill  <none>
pn  xinput  <none>

-- no debconf information



More information about the Pkg-acpi-devel mailing list