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