[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