Sky2 driver dies some time after resume

Sky2 driver dies some time after resume

[Mauro Carvalho Chehab]

Hi Stephen,

I've noticing a weird behavior on sky2 driver after returning from
suspend. 

After returning, the driver works as expected. However, after some usage
at the interface, it behaves like if the network were down.

The workaround I'm currently using is manually removing sky2 driver and
reinserting.

This bug is present on all kernel versions I tested on this machine,
since when I bought it, on Feb, 2007. I'm currently running 2.6.20.7 on
this notebook.

The SKY2 hardware is:

02:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88E8038 PCI-E Fast Ethernet Controller [11ab:4352] (rev 14)
        Subsystem: Gateway 2000 Unknown device [107b:0367]
        Flags: bus master, fast devsel, latency 0, IRQ 318
        Memory at c0200000 (64-bit, non-prefetchable) [size=16K]
        I/O ports at a000 [size=256]
        Capabilities: [48] Power Management version 2
        Capabilities: [50] Vital Product Data
        Capabilities: [5c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+
        Capabilities: [e0] Express Legacy Endpoint IRQ 0
        Capabilities: [100] Advanced Error Reporting

-- 
Cheers,
Mauro

Re: Sky2 driver dies some time after resume

[Stephen Hemminger]

On Mon, 21 May 2007 18:29:17 -0300
Mauro Carvalho Chehab <mchehab@infradead.org> wrote:

> Hi Stephen,
> 
> I've noticing a weird behavior on sky2 driver after returning from
> suspend. 
> 
> After returning, the driver works as expected. However, after some usage
> at the interface, it behaves like if the network were down.
> 
> The workaround I'm currently using is manually removing sky2 driver and
> reinserting.
> 
> This bug is present on all kernel versions I tested on this machine,
> since when I bought it, on Feb, 2007. I'm currently running 2.6.20.7 on
> this notebook.
> 
> The SKY2 hardware is:
> 
> 02:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88E8038 PCI-E Fast Ethernet Controller [11ab:4352] (rev 14)
>         Subsystem: Gateway 2000 Unknown device [107b:0367]
>         Flags: bus master, fast devsel, latency 0, IRQ 318
>         Memory at c0200000 (64-bit, non-prefetchable) [size=16K]
>         I/O ports at a000 [size=256]
>         Capabilities: [48] Power Management version 2
>         Capabilities: [50] Vital Product Data
>         Capabilities: [5c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+
>         Capabilities: [e0] Express Legacy Endpoint IRQ 0
>         Capabilities: [100] Advanced Error Reporting
> 

Which distro? some scripts are different.

Also, check if MSI is being restore properly on resume. There are some BIOS's
that muck with MSI when ACPI calls them during resume. On Sony VAIO laptop,
I needed to disable MSI or it resume wouldn't work.

Linus also reported some oddness where the driver couldn't send big packets.
Could you try:
	ethtool -r eth0
That causes a phy renegotiation .

-- 
Stephen Hemminger <shemminger@linux-foundation.org>

Re: Sky2 driver dies some time after resume

[Mauro Carvalho Chehab]

> > I've noticing a weird behavior on sky2 driver after returning from
> > suspend. 

> Which distro? some scripts are different.

I'm using Mandriva 2007.1.

I'm hibernating here by using
	/usr/bin/klaptop_acpi_helper --hibernate

I'm not sure what scripts klaptop is using (kde version is 3.5.6).

If you want, I may run some hibernation script instead.

> Also, check if MSI is being restore properly on resume. There are some BIOS's
> that muck with MSI when ACPI calls them during resume. On Sony VAIO laptop,
> I needed to disable MSI or it resume wouldn't work.

ACPI seems to work badly on this Gateway notebook. I'm loading kernel
with noacpi. Probably, this will also disable MSI.
> 
> Linus also reported some oddness where the driver couldn't send big packets.
> Could you try:
> 	ethtool -r eth0
> That causes a phy renegotiation .

I did the following procedure, after hibernation:

# ping -f otherhost
	(worked as expected)

# ping -f otherhost -s 500
	(worked as expected)

# rsync -vuza otherhost:/sometree .

At the middle of the transfer, network stopped work.

# ethtool -r eth0

Didn't worked (I ran this several times)

dmesg (after emerging from hibernation):

CPU1 is up
usb usb2: root hub lost power or was reset
sky2 eth0: Link is up at 100 Mbps, full duplex, flow control none
usb 3-6: USB disconnect, address 8
usb 3-6: new high speed USB device using ehci_hcd and address 9
usb 3-6: configuration #1 chosen from 1 choice
sky2 eth0: Link is down.
sky2 eth0: Link is up at 100 Mbps, full duplex, flow control none
sky2 eth0: Link is down.
sky2 eth0: Link is up at 100 Mbps, full duplex, flow control none
sky2 eth0: Link is up at 100 Mbps, full duplex, flow control none

# ethtool eth0

Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Current message level: 0x000000ff (255)
        Link detected: yes

# rmmod sky2; modprobe sky2; dmesg

sky2 eth0: disabling interface
ACPI: PCI interrupt for device 0000:02:00.0 disabled
ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:02:00.0 to 64
sky2 v1.10 addr 0xc0200000 irq 16 Yukon-FE (0xb7) rev 1
sky2 eth0: addr 00:e0:b8:ba:33:39
sky2 eth0: enabling interface
sky2 eth0: ram buffer 4K
ADDRCONF(NETDEV_UP): eth0: link is not ready
sky2 eth0: Link is up at 100 Mbps, full duplex, flow control none
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Now, network is working like a charm.

I suspect that something weird occurs with big packets after
hibernation.

> 
-- 
Cheers,
Mauro