sky2 ethernet driver is freezing on big upload

this is also happening to me. Only ocassionally.

Bug #37164

Another bugreport for same problem:
Bug #37771

in linux-image-2.6.15-20 this issue fixed for me at least. It seem to be working. In the meantime bug report 33230 giving more information for this bug. Some people said that it still does not works for some systems

Ben Collins has backported the sky2 driver from 2.6.16.13. It will be in the next kernel upload. it should fix this bug.
Please test when it is available and let us know.

I noticed that after performing a dist-upgrade this morning (which included a new kernel image, but not restricted-modules, which it claimed was broken due to unmet deps) the version of sky2 has changed from 1.1 to 0.15.

However, it's still not working. I tried scp'ing ~30 megs of /dev/urandom data to a remote host (obviously after a reboot to load the new kernel), and it still hangs after a couple of megabytes.

This is with linux-image-2.6.15-23-686.

For me it just got worse, linux-image-2.6.15-23-686 nearly doesn't work at all. It locks up almost immediately and after that only very small amount of data slips thru, e.g ping to another site and it possible to ssh to another site but after that i just hangs.

linux-image-2.6.15-22-686 worked perfectly for me, sky2 version 1.1.

My ethernet controller is: Marvell Technology Group Ltd. 88E8053 Gigabit Ethernet Controller (rev 15)

Since originally getting this bug, I've done a fresh install of Dapper and have upgraded to kernel 2.6.15-25-686 (sky2 ver 1.4) and I'm still having the same problems. Same also happens with 2.6.15-15-386 (also sky2 1.4). Are there any other fixes for this bug in the pipeline?

Upgraded to 2.6.15-26-686 (sky2 ver 1.4 again), same problem, just so you know...

The problem still exists in 2.6.20-13. It was in 2.6.15, 2.6.17, and is still here in 2.6.20. It was neve fixed.

This problem has been there since 6.0.6 Ubuntu and Kubuntu, this issue has NOT been fix at all,
I have report this issue several times, in the past... this is a Major Bug,

Rich

I also had this kind of problem in Dapper, Edgy and now Feisty.

Try 2.6.20-14 from the daily ISO at http://cdimage.ubuntu.com/daily-live/current as it has some sky2 transmit timeout fixes from upstream entitled "sky2: transmit timeout deadlock".

I have a fully up to date Feisty install and had to sudo rmmod sky2/sudo modprobe sky2 today.

How about trying this version that I back ported from 2.6.21-rc6:

cd /lib/modules/2.6.20-14-generic/kernel/drivers/net
sudo cp sky2.ko sky2.ko.old
sudo wget -O sky2.ko http://people.ubuntu.com/~rtg/sky2.ko.2.6.20-14
sudo modprobe -r sky2
sudo modprobe sky2

Please attach dmesg output if you continue to have failures.

This is my dmesg output after a driver freeze when trying the above method with the backported driver from 2.6.21-rc6. I'm using 2.6.20-15-generic kernel on Feisty.

[ 8050.980000] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 17
[ 8050.980000] PCI: Setting latency timer of device 0000:02:00.0 to 64
[ 8050.980000] sky2 0000:02:00.0: unsupported chip type 0xff
[ 8050.980000] ACPI: PCI interrupt for device 0000:02:00.0 disabled
[ 8050.980000] sky2: probe of 0000:02:00.0 failed with error -95

I attached the ethernet part of my sudo lspci -vv output.

Problem here too. Ever since dapper... What's up with that?

----- Original Message -----
> Problem here too. Ever since dapper... What's up with that?
>
> --
> sky2 ethernet driver is freezing on big upload
>
> You received this bug notification because you are a direct subscriber
> of the bug.

"What's up with that" is that the dev is unable to reproduce the bug (see:http://developer.osdl.org/shemminger/blog/?p=34 ) . The driver works perfectly on his hardware. Additionally, he wrote the driver while under an NDA, so there are no public specifications available for anyone else to fix the driver unless they reverse engineer the Windows one. There are only two ways (that I can think of) to fix it:
1. Get a card that has issues with sky2 and give it to the Hemminger to work with. I thought about doing this because I only use wired connections at school (have wifi at home...and thanks to this bug + having Centrino, I have the odd case of better wifi than wired on Linux), but it turns out it's onboard (unlike the wireless which is just mini-pci), so unless I sent my whole laptop, it'd be impossible.
2. Someone with this issue either admits that they have the expertise or gains the expertise to reverse engineer the Windows driver and see what's going wrong. I'm guessing it's something to do with memory/buffers, and also guessing the Windows driver would have those numbers in it. Then they can either give the information to Hemminger or, if they're comfortable with messing around in kernelspace, try to fix the driver on their own.

At this point, I'm considering #2 as a possibility (I suspect that all Marvell Yukon 2 cards are onboard). I don't know how to do any of that stuff, but I have a copy of Linux Device Drivers 3 (which I got because I want to write a driver to make a USB device I have work), the text of which is available at http://lwn.net/Kernel/LDD3/ for anyone else wanting a look (it's released CC-SA, so that's legal, but I like having real books for offline-coding-time, like on 8-hour train-rides). Like I said, though, fixing it up would require reverse engineering the driver. If anyone else is willing to try to figure this out, that'd be great. Two (or three, or four...) heads are better than one, and someone on this bug report probably has a lot more C experience than I do. I'm not really comfortable messing around in kernelspace, but I don't see it getting fixed unless one of us gets fed up and does it, so I'll read and ask questions of a few kernel hackers I know, and if anyone wa
nts to join me on the bug-hunt, maybe as a group we can figure out the problem and patch it.

Sorry, my tone was certainly uncalled for. I'm no c programmer so would be of no help coding but I would be happy to send devs output to help diagnose the problem. My adapter is onboard

lscpi:
[code]02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 19)[/code]

What versions of the driver have you tried? I had this exact same bug back in breezy / dapper flight 6. I have the same onboard NIC you have as well. While I can't say I'm 100% positive that the bug is fixed I was 90% sure that it was fixed since I use some very graphics intensive XWindows apps on my campus...usually spikeing traffic to 10+mbs...and these were the same apps that were causing me trouble in the first place. I am absolutely positive I don't have anything current, but I know there was a similar bug in the windows driver for this card, involving a buffer that was defaulted to have its value set too low. I pointed this out a year or two ago, and the bug appeared to go away after someone backported a driver to the current ubuntu version of the kernel. I'll try to get both the link to the issue with the Windows driver, and my current version of the kernel + driver as soon as I can, but I'm at work without the computer in question.

I've used every shipped driver since Dapper (now on feisty) -- the network now only hangs very rarely whereas with dapper it was a frequent occurence. Now when it goes out, it seems to be when I'm downloading something sizable. I'll go away and when I come back, the network has hung. I suppose it is possible that it is not the driver's fault as an "rmmod sky2" and "modprobe sky2" does not bring the network back online. I did install the sk98lin driver yesterday -- I'll post an update if I get another hang.

Well having same problems using last feisty, ethernet diver crash, and hangs, tested with this setup:
Board: Gigabyte 965P-S3
root@virtual:~# uname -a
Linux virtual 2.6.20-16-server #2 SMP Thu Jun 7 19:05:27 UTC 2007 x86_64 GNU/Linux

root@virtual:~# lspci
00:00.0 Host bridge: Intel Corporation 82P965/G965 Memory Controller Hub (rev 02)
00:01.0 PCI bridge: Intel Corporation 82P965/G965 PCI Express Root Port (rev 02)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #4 (rev 02)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #5 (rev 02)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI #2 (rev 02)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 02)
00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 02)
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #3 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev f2)
00:1f.0 ISA bridge: Intel Corporation 82801HB/HR (ICH8/R) LPC Interface Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801H (ICH8 Family) 4 port SATA IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 02)
00:1f.5 IDE interface: Intel Corporation 82801H (ICH8 Family) 2 port SATA IDE Controller (rev 02)
01:00.0 VGA compatible controller: ATI Technologies Inc Unknown device 5657
01:00.1 Display controller: ATI Technologies Inc Unknown device 5677
03:00.0 SATA controller: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 02)
03:00.1 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 02)
04:00.0 Ethernet controller: Marvell Technology Group Ltd. Unknown device 4364 (rev 14)

lspci -vv
04:00.0 Ethernet controller: Marvell Technology Group Ltd. Unknown device 4364 (rev 14)
        Subsystem: Giga-byte Technology Unknown device e000
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at f7000000 (64-bit, non-prefetchable) [size=16K]
        Region 2: I/O ports at b000 [size=256]
        [virtual] Expansion ROM at 80000000 [disabled] [size=128K]
        Capabilities: [48] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=1 PME-
        Capabilities: [50] Vital Product Data
        Capabilities: [5c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
  ...

It seems to work properly in Gutsy. Can anyone else confirm that the Gutsy kernel has a properly working version of the driver?

There is a known issue with the 8053 -EC network controller firmware related to this, and found that moving to firmware v2.2 resolves a bunch of issues - you need to contact your motherboard vendor for this.

Firmware version checking DOS tool:
http://www.marvell.com/drivers/files/yukondg_v6.53.4.3.zip

More info:
http://marc.info/?l=linux-netdev&m=121967539303140&w=2

The 18 month support period for Feisty Fawn 7.04 has reached it's end of life. As a result, we are closing the linux-source-2.6.20 Feisty Fawn kernel task. However, please note that this report will remain open against the actively developed kernel. Thank you for your continued support and help as we debug this issue.

Marvell Technology Group Ltd. 88E8040 on 2.6.27-7-generic doesn't work!

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.