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 [off-list ref] :
[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656331]

quoted

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