| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <1328714917.3483.21.camel@mattotaupa>
Date: Wed, 08 Feb 2012 16:28:37 +0100
From: Paul Menzel <pm.debian@...glemail.com>
To: Francois Romieu <romieu@...zoreil.com>
Cc: nic_swsd@...ltek.com, 656331@...s.debian.org,
netdev@...r.kernel.org, Hayes Wang <hayeswang@...ltek.com>
Subject: Re: Bug#656331: RTL8168b/8111b with ASUS M2A-VM (SB600): Network
device stays down after resume
Dear Francois,
thank you for your fast reply.
Am Sonntag, den 05.02.2012, 18:57 +0100 schrieb Francois Romieu:
> Paul Menzel <pm.debian@...glemail.com> :
> [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656331]
> > I experienced this problem (only) three times until now. If I remember
> > correctly the last time with 3.2.1. I still do not know how to reproduce
> > this.
>
> (good PR, nice)
>
> An 'ethtool -d' and a 'mii-tool -v' of the device after a successful resume
> and a failed one could help if it's a driver thing.
The problem has not shown up again until now so I only send the output
from the successful resume. Currently Linux version 3.2.4 is installed.
The following outputs are identical after startup and (a successful)
resume.
$ sudo ethtool --version
ethtool version 3.1
$ sudo ethtool eth0 # The option `-d` does not exist.
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Link partner advertised pause frame use: Symmetric
Link partner advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
drv probe ifdown ifup
Link detected: yes
$ sudo mii-tool --version
$Id: mii-tool.c,v 1.9 2006/09/27 20:59:18 ecki Exp $
(Author: David Hinds based on Donald Becker's mii-diag)
net-tools 1.60
$ sudo mii-tool -v
eth0: negotiated 100baseTx-FD flow-control, link ok
product info: vendor 00:07:32, model 17 rev 2
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> You may check if runtime power management is enabled or not, especially
> after a failed resume. See the /sys/devices/pci....:../....:..:..../power
> directory and its control, runtime_enabled and runtime_status files
> (control = on -> runtime PM disabled, see Documentation/power/runtime_pm.txt)
The document is online at [1].
For some reason the ethernet controller is not listed under
`/sys/devices`.
$ lspci | grep RTL
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
$ lspci -n -s 02:00.0
02:00.0 0200: 10ec:8168 (rev 01)
$ ls /sys/devices/
breakpoint i2c-2 LNXSYSTM:00 pnp0 tracepoint
cpu i2c-3 pci0000:00 software virtual
i2c-1 i2c-4 platform system
I use `/sys/bus/pci/devices` instead.
$ more /sys/bus/pci/devices/0000\:02\:00.0/power/{control,runtime_enabled,runtime_status}
::::::::::::::
/sys/bus/pci/devices/0000:02:00.0/power/control
::::::::::::::
on
--More--(Next file: /sys/bus/pci/devices/0000:02:00.0/power/runtime_::::::::::::::
/sys/bus/pci/devices/0000:02:00.0/power/runtime_enabled
::::::::::::::
forbidden
--More--(Next file: /sys/bus/pci/devices/0000:02:00.0/power/runtime_::::::::::::::
/sys/bus/pci/devices/0000:02:00.0/power/runtime_status
::::::::::::::
active
> If it is enabled and the link does not come up fast enough (5 s), runtime
> PM will suspend the device. It should not matter as long as the link is
> still present because the device should (TM) soon generate a power management
> event. The latter not happening or the PME being ignored could explain
> the bug. If so, temporarily disabling runtime PM for your device after a
> failed resume instead of removing the module or the cable may be enough
> to recover the link. It's just a guess though.
So judging from the output above runtime power management is disabled
after a fresh boot and (a successful) resume and something else went
wrong.
I will report back as soon as I get a failed resume.
> Please stay with v3.2 or above in the meantime.
I will.
Thanks,
Paul
[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/power/runtime_pm.txt;h=4abe83e1045a4b38e85b05ebfeb3e8e62841a7f6;hb=HEAD
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
Powered by blists - more mailing lists