Sky2 driver dies some time after resume

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

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 <[email protected]>

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.

ACPI seems to work badly on this Gateway notebook. I'm loading kernel with noacpi. Probably, this will also disable MSI.

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