Distribution: OpenSuSE 10.1 Hardware Environment: Toshiba Satellite M45-S355 Problem Description: Is impossible transfer files with more than 1Mb by ethernet using module sky2 on Marvell 88E8036. When I try transfer this files, the ethernet failure and brake (I need use modprobe to reload module sky2). I found this problem in Kernel 2.6.16.13-4 (SuSE), but I compile kernel 2.6.17.4 and the same problem still exist. See more in https://bugzilla.novell.com/show_bug.cgi?id=182541#c8 dmesg output: https://bugzilla.novell.com/attachment.cgi?id=88761 winfo --netcard: https://bugzilla.novell.com/attachment.cgi?id=88762 Best regards, Renato Yamane BRAZIL
Created attachment 8590 [details] sky2 napi race
Patch submitted for 2.6.18 and 2.6.17.X kernel that fixes a NAPI race in sky2 driver
Hemminger, I applied this patch and tested, but the problem continue. I make this: # cd /usr/src/linux-2.6.17.6 # patch -p1 < sky2.patch # make xconfig I save the .config file and select sky2 as module: # cat .config | grep -i sky2 CONFIG_SKY2=m # make After few minutes, I copy System.map, bzImage to /boot (edit GRUB) and make a initrd. I try transfer a file (11Mb) to another computer (by samba, because the another machine use MS Win XP) and the module sky2 crash again (I need reload sky2 with modprobe). Best regards, Renato S. Yamane
Did you remember to install the new module? # make modules_install
Ops... I forgot to write here, but I installed the modules with #make modules_install Thanks, Renato S. Yamane
Detail: I apply this patch in Kernel 2.6.17.6 (not 2.6.17.4) It's OK? After I type "patch -p1 ..." I receive a message shown that patch it was applied in driver/net/sky2.c Thanks, Renato Yamane
More info: I can transfer files from another machine TO my laptop, but the inverse is impossible (copy files from my laptop to another machine). In old Kernel (e.g. OpenSuSE 10.0) the module to my ethernet card was sk98lin and I don't have this problem (but I have anothers serious problem with sk98lin). With sky2 my only problem is with transfer files by ethernet. Best regards, Renato Yamane
I have a same problem. Ethernet Interface 07:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8036 PCI-E Fast Ethernet Controller (rev 15) Subsystem: Sony Corporation Unknown device 81e6 Flags: bus master, fast devsel, latency 0, IRQ 185 Memory at d8000000 (64-bit, non-prefetchable) [size=16K] I/O ports at 3000 [size=256] Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable- Capabilities: [e0] Express Legacy Endpoint IRQ 0 Capabilities: [100] Advanced Error Reporting Kernel Instaled cat /proc/version Linux version 2.6.16.21-0.13-smp (geeko@buildhost) (gcc version 4.1.0 (SUSE Linux)) #1 SMP Mon Jul 17 17:22:44 UTC 2006 Module Version ethtool -i eth0 driver: sky2 version: 0.15 firmware-version: N/A bus-info: 0000:07:00.0 The adapter works, start using networkmanager, but if start the transfer files to another machine, or send printing, or send email to attach file (TX mode) the adapter died. I need to down an up interface. This problem is present in ANY times to transfer files.
Bug should be fixe as of 2.6.17.7 or later. Reopen if it still happens.
Stephen, you send me in PVT a e-mail with last version of sky2 driver (version 1.7) but I reply to you informing that this driver still have problem. And I tested with Kernel 2.6.18RC3 and the same problem still exist. Please, comment. Best regards, Renato Yamane
Correcting: You send me version 1.6 of sky2 driver (in 07/31/2006). This problem still exists (tested in kernel 2.6.18RC3 comment in our PVT messages).
Renato, Could you please try "ethtool" to turn autonegotiation off? ethtool -A eth1 autoneg off rx on tx on and run ethtool -a eth1 to check if it is indeed turned off? I had the same problem as you. Like you sky2 v1.6 did not help, but the above seems to have fixed my problem
Wowwww! This work-arround fix this problem! # uname -a Linux mandachuva 2.6.18-rc3-default #1 Tue Aug 1 23:33:59 BRT 2006 i686 i686 i386 GNU/Linux Some information about my Ethernet controller: ============= Model: "Toshiba America Info Marvell 88E8036 Fast Ethernet Controller (Inventec)" Vendor: pci 0x11ab "Marvell Technology Group Ltd." Device: pci 0x4351 "88E8036 PCI-E Fast Ethernet Controller" SubVendor: pci 0x1179 "Toshiba America Info Systems" SubDevice: pci 0xff10 "Marvell 88E8036 Fast Ethernet Controller (Inventec)" Revision: 0x10 Driver: "sky2" Device File: eth1 Memory Range: 0xcc000000-0xcc003fff (rw,non-prefetchable) I/O Ports: 0xc000-0xdfff (rw) IRQ: 11 (5998 events) HW Address: 00:a0:d1:24:bc:c1 Link detected: yes Module Alias: "pci:v000011ABd00004351sv00001179sd0000FF10bc02sc00i00" Driver Info #0: Driver Status: sky2 is active Driver Activation Cmd: "modprobe sky2" Config Status: cfg=no, avail=yes, need=no, active=unknown Attached to: #12 (PCI bridge) ============= # ethtool -i eth1 driver: sky2 version: 1.6 firmware-version: N/A bus-info: 0000:01:00.0 # ethtool -A eth1 autoneg off rx on tx on # ethtool -a eth1 Pause parameters for eth1: Autonegotiate: off RX: on TX: on I don't close this bug, because this solution is only "work-arround". Best regards, Renato S. Yamane
The real reason my work-around seems to work, is that it forces the interface into 100baseTx-HD mode. Renato, could you please try this instead? ethtool -s eth1 speed 100 duplex half autoneg off BTW, if I don't specify autoneg off explicitly, eth1 (actually eth0 for me) goes back to full duplex. Should it be that way? Moreover, I cannot use mii-tool to force any speed. Interface keeps switching back to 100baseTx-FD. Stephen, any ideas? Thanks, -manuj
-manuj, I try your suggestion and this solve the problem too. # ethtool -s eth1 speed 100 duplex half autoneg off With this options in ethtool, I can transfer files TO ANOTHER machine without problem :-) I don't know how I can check the real speed (100Mbps?) and if duplex mode (half or full) is "on", but the command #ethtool comment above don't return error message, so I think that my ethernet is work in duplex mode and with 100Mbps speed :-) Best regards, Renato S. Yamane
I tested to see if I could use the sky2 driver v1.5 in 2.6.18-rc6 and the problem still exists. The device stalls when the load gets to much, which happens just after a minute with a highspeed internet connection. The test was done on a Toshiba Tecra A5 Laptop with ethernet device as stated below: Ethernet controller: Marvell Technology Group Ltd. 88E8036 Fast Ethernet Controller (rev 10) Subsystem: Toshiba America Info Systems Marvell 88E8036 Fast Ethernet Controller (Compal) Flags: bus master, fast devsel, latency 0, IRQ 169 Memory at b4000000 (64-bit, non-prefetchable) [size=16K] I/O ports at 3000 [size=256] Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable- Capabilities: [e0] #10 [0011] I have managed to get it to work better with the sk98lin driver from 2.6.15 and patched with the syskonnect patch. But it only works when pci=routeirq is used. This is not a good solution for me since upgrading and other things get rather impossible. best regards Steven Hellingh
Compiled 2.6.17.13 which included some patches for sky2. Sadly I must report that "heavy" load still makes the driver unusable.
I have the same issue with kernel 2.6.18-rc7, it just freezes the network card under heavy load. Using standard Ubuntu Dapper with latest 2.6.18-rc7 : ethtool -i eth1 driver: sky2 version: 1.5 firmware-version: N/A bus-info: 0000:02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 19) Is there any way to fix this ? This has been around for quite some time.
The problem not fixed in suse kernel 2.6.16.21-0.13-smp. Exist any possibility to this bug fixed in this year?!
FRLinux, you can use a work-arround (by Manuj) to fix this problem. Disable autonegotiate: #ethtool -A ethX autoneg off rx on tx on Best regards, Renato S. Yamane
Using this work around solution, my network card decrease its speed drastically, when doing network transations like "scp"... Is there some possible improviment to keep the ethernet working, but faster? ----- Mensagem original ---- De: "bugme-daemon@bugzilla.kernel.org" <bugme-daemon@bugzilla.kernel.org> Para: euricovaz@yahoo.com.br Enviadas: Quarta-feira, 20 de Setembro de 2006 10:51:58 Assunto: [Bug 6839] sky2 failure on heavy load http://bugzilla.kernel.org/show_bug.cgi?id=6839 ------- Additional Comments From renatoyamane@mandic.com.br 2006-09-20 07:42 ------- FRLinux, you can use a work-arround (by Manuj) to fix this problem. Disable autonegotiate: #ethtool -A ethX autoneg off rx on tx on Best regards, Renato S. Yamane ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. _______________________________________________________ O Yahoo! est
Created attachment 9057 [details] TX pause fix Needed to make sure TX pause packets were processed. Otherwise any transmit flow control would make transmitter get stuck
*** Bug 7167 has been marked as a duplicate of this bug. ***
Stephen, the problem still exists whith this patch in Kernel 2.6.18 (release in 09/20/2006). None messages is present in /var/log/messages! Is impossible transfers files with autonegotiate is ON Eurico, with this work-arround I can tranfers files with max 100Kb/sec... Yes, is too slow!
Stephen Hemminger wrote: >> Is impossible transfers files with autonegotiate is ON > > Then you have a problem with the hardware on the other side of the connection. > That problem is unrelated to the problem reported by this bugzilla bug. No my friend! Other side is OK, I test in my home network and in work network (corporation). With MS Windows XP I can transfer files without problems in the same network (home and work too). This problem (with autonegotiate) is reported in comment 12 Best regards, Renato
Created attachment 9068 [details] /var/log/messages when "sky2 eth1 tx timeout" happened We also see "tx timeout" problem with the latest version 1.7 of sky2.c. Although we are using rather old kernel (2.6.16.1) I copied sky2.[hc] version 1.7 from linux-2.6.18-rc7-mm1 with some minor changes to make it build under our version of kernel. I would love to help to debug this problem. Please let me know if more info is need or if there is a debugging/instrumented version of the driver that I can try. Thanks, Vladimir Stepanenko
Sirs, I think that we are saying different things :-) Our problem is with sky2 driver, but NOT with tx timeout. I (and other users in this bugzilla. See comments) don't have problem with tx timeout in my Toshiba America Info Marvell 88E8036 Fast Ethernet Controller (Inventec). Our problem is with sky2 driver, but the problem exists ONLY WHEN "autonegotiate" is ON. So, the problem in sky2 driver is in autonegotiate and NOT in TX mode (see comment 12) We cannot transfers large files in network when AUTONEGOTIATE is ON. When we try transfer LARGE FILES, our sky2 driver failure and we need reload this driver. NONE output in /var/log/messages or in dmesg is created about this error. We are synchronized now? :-) Please others guys... use this parameters (See comment 12) and try transfers large files again. Only me and "justforkix" test this work-arround, and with autonegotiate OFF we can transfer large files without problem. Best regards, Renato
# uname -r 2.6.18-default # ethtool -i eth1 driver: sky2 version: 1.5 firmware-version: N/A bus-info: 0000:01:00.0 None output is created in /var/log/messages or in dmesg when sky2 driver failure on heavy load. Don't forgot to read comment 12 and comment 27 Best regards, Renato Yamane
Yes, there is another bug (http://bugzilla.kernel.org/show_bug.cgi?id=7167) about sky2 tx timeout. It marked as duplicate of 6839 though. Should I change status of 7167 back to assign? Thanks, Vladimir Stepanenko
Vladimir, unhappyly only me and manuj ("justforkix") disable autonegotiate and write result here, but to we, the problems keep out with this work-arround (comment 12). In my logs, problems with TX-Timeout is NOT detected. Bugs 6839 and 7167 have the same problem (sky2 failure with heavy load), BUT I think that the causes are differents. Datail: My network card is Marvell Yukon 88E8036 (Toshiba Laptop) and in bug7167 the network card is a Marvell Yukon 88E8053. Best regards, Renato S. Yamane
Oups, sorry for the mistake. In fact I've just verified what is the model of my network card and in fact it is NOT a 88E8053 marvell yukon but a 88E8036 marvell yukon card (in fact this is the embedded network card of a M40-245 toshiba laptop). So the bug 7167 should be merged with the 6839 bug. seb 2006/9/22, bugme-daemon@bugzilla.kernel.org <bugme-daemon@bugzilla.kernel.org>: > http://bugzilla.kernel.org/show_bug.cgi?id=6839 > > > > > > ------- Additional Comments From renatoyamane@mandic.com.br 2006-09-21 16:26 ------- > Vladimir, > unhappyly only me and manuj ("justforkix") disable autonegotiate and write > result here, but to we, the problems keep out with this work-arround (comment 12). > > In my logs, problems with TX-Timeout is NOT detected. > > Bugs 6839 and 7167 have the same problem (sky2 failure with heavy load), BUT I > think that the causes are differents. > > Datail: My network card is Marvell Yukon 88E8036 (Toshiba Laptop) and in bug > 7167 the network card is a Marvell Yukon 88E8053. > > Best regards, > Renato S. Yamane > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. >
#cat /var/log/messages | grep -i tx kernel: sky2 0000:01:00.0: No interrupt was generated using MSI, switching to INTx mode. Please report this failure to the PCI maintainer and include system chipset information This is my only log about TX Mode, but this error don't crash my sky2 driver on heavy load. Sebastien, please, try transfer large files with autonegotiate OFF: #ethtool -s eth1 speed 100 duplex half autoneg off Use this parameters above and try transfer large files in your network. Best regards, Renato S. Yamane
NEWS: I send a file to print in a network printer (192.168.1.30, port 9100) and now I receive a TX Timeout error: Sep 22 10:30:44 mandachuva dhclient: DHCPREQUEST on eth1 to 192.168.1.3 port 67 Sep 22 10:30:54 mandachuva dhclient: DHCPREQUEST on eth1 to 192.168.1.3 port 67 Sep 22 10:31:03 mandachuva kernel: NETDEV WATCHDOG: eth1: transmit timed out Sep 22 10:31:03 mandachuva kernel: sky2 eth1: tx timeout Sep 22 10:31:03 mandachuva kernel: sky2 eth1: transmit ring 468 .. 445 report=471 done=471 Sep 22 10:31:03 mandachuva kernel: sky2 status report lost? Sep 22 10:31:08 mandachuva kernel: NETDEV WATCHDOG: eth1: transmit timed out Sep 22 10:31:08 mandachuva kernel: sky2 eth1: tx timeout Sep 22 10:31:08 mandachuva kernel: sky2 eth1: transmit ring 468 .. 445 report=471 done=471 Sep 22 10:31:08 mandachuva kernel: sky2 status report lost?
Dear Renato, Our problems are indeed "tx timeout". We are just not patient enough to wait that long! If I understand it correctly, the marvell chip has a TX queue (a ring?) The TX timeout messages show up once the queue gets full. For some reason, perhaps by design, the tx packets queue slows down after the TX channel hangs, and it took about 7-8 mins for "tx timeout" to show up in my logs. Unfortunately, my "work around" has led to some confusion. By switching off autoneg, the link partner switches itself to "half duplex" mode. This is the real reason why the work-around works :) When I connected my laptop directly to the server, and forced "full duplex" on both sides, the connection predictably hung. Moreover, I now suspect that flow control is not responsible for this issue. I have been doing some tests with netcat as well as "raw" sockets. One thing that has come out is that the RX channel continue to work, even when our TX part hangs. I've quite a few things to figure out with packet/sockets and can not state this with confidence, but I think the hardware actually transmits some packets but does not signal to the driver that it has done so. Should have more later, if the problem persists -manuj
*** Bug 7187 has been marked as a duplicate of this bug. ***
Created attachment 9079 [details] Link partner ability match for gigabit Need to look at the proper register to see if link partner can do gigabit/full duplex.
Created attachment 9106 [details] Log after gigabit patch I don't have a gigabit lan, so I think that is impossible test this patch. When I load sky2 module, I see this in dmesg: "Link is up at 100 Mbps, half duplex, flow control none" But, the problem with heavy load (failure sky2) still exists with this patch too. Log in attachment. Best regards, Renato S. Yamane
*** Bug 7224 has been marked as a duplicate of this bug. ***
Steven, Your last patch http://bugzilla.kernel.org/attachment.cgi?id=9079&action=view seems to fix "tx timeout" problem for me. And I am using gigabit connection. Thanks a lot, Vladimir
I have an onboard Marvel 88E8036 Network Card. My transmitter locks up, too with kernel 2.6.18-gentoo. Disabling the autonegotiation seems to work however the data transfer rate drops to 102Byte/s after transfering about 20 MByte at full speed (100MBit Network). I have tried the patch http://bugzilla.kernel.org/attachment.cgi?id=9079&action=view but it didn't work. The transmitter locks up as without the patch. I will add my dmesg output as an attachment as it is very long.
Created attachment 9134 [details] dmesg output from kernel 2.6.18-gentoo with transmitter lockup Attachment for comment #40.
Hi, taking the current version of the driver out of git has fixed the lockups for me. The machine is stable even under heavy load. Without disabling auto negotiation. Philip
Can someone send me sky2 module available in 2.6.18.git22 to compile in Kernel my Kernel 2.6.18? Thanks, Renato
The problem still exists in Kernel 2.6.18.1 Best regards, Renato Yamane
Comment on attachment 9057 [details] TX pause fix This patch doesn't work
Comment on attachment 9079 [details] Link partner ability match for gigabit not the problem
Created attachment 9279 [details] Allow multicast Pause packets 802.3 says other end may send Unicast or Multicast pause packets for flow control. The driver was ignoring multicast pause packets.
I try use this patch, but when I run "make" I receive this error message: # patch -p1 < sky2.patch patching file drivers/net/sky2.c # modprobe -r sky2 # make CHK include/linux/version.h CHK include/linux/utsrelease.h CHK include/linux/compile.h CC [M] drivers/net/sky2.o drivers/net/sky2.c: In function
Hello, I have kernel 2.6.18.1 and my Marvel Yukon using sky2 module is still broken. Every time I try to send some high trafic thru my eth0 all the networking stops. This mostly happens when I try to print something which is big. Like some MB of image sent to the printer stops the network. Can somebody please help me ? Maybe sending a patch for solve this problem ? Many thanks in advance !! Sasa Ostrouska casaxa@gmail.com
Created attachment 9286 [details] Receive multicast pause packets This patch is against 2.6.18 version of driver.
Comment on attachment 9279 [details] Allow multicast Pause packets This version was for 2.6.19-rc1
I use patch about "multicast pause packets", but the problem still exists in Kernel 2.6.18.1 When I transfer large files **TO ANOTHER** machine (or printer), sky2 crash. I can transfer large files to MY machine without problem, but to ANOTHER machine is impossible. Best regards, Renato Yamane
Created attachment 9287 [details] Don't process pause packets Don't want to pass pause packets up the protocol stack. This patch is for 2.6.18.1 only. The problem was introduced after 2.6.18
Stephen, I use this two last patches in Kernel 2.6.18.1: - Receive multicast pause packets - Don't process pause packets Now I can transfer files with a bit more size (<= 2Mb), but I still can't transfer files with big sizes (>=2Mb). I test with a folder of 17Mb (some jpeg files), but I can transfer *only* 1.7Mb... after this sky2 crash :-( Best regards, Renato Yamane
Created attachment 9313 [details] Yukon FE ram buffer initialization There was a misconfiguration on 88E803X chips, that cause receive and transmit to share the same space!
Stephen, this patch (Yukon FE ram buffer initialization) fix this problem! Now I can transfer files to another computers without problems! Tested on Kernel 2.6.18.1 How can I send a donation to you? Best regards, Renato S. Yamane
I tested the patch on 2.6.18.1 and it seems that resolvs the bug smb: \> put ubuntu-6.06-server-i386.iso putting file ubuntu-6.06-server-i386.iso as \ubuntu-6.06-server-i386.iso (8712.0 kb/s) (average 8712.0 kb/s) smb: \> put ubuntu-6.10-beta-desktop-i386.iso putting file ubuntu-6.10-beta-desktop-i386.iso as \ubuntu-6.10-beta-desktop-i386.iso (7690.2 kb/s) (average 8056.0 kb/s) smb: \> ls . D 0 Sat Oct 21 17:29:06 2006 .. D 0 Sat Oct 21 17:29:06 2006 ubuntu-6.06-server-i386.iso A 452603904 Sat Oct 21 17:28:37 2006 ubuntu-6.10-beta-desktop-i386.iso A 716517376 Sat Oct 21 17:30:37 2006 These was not possible before, I'll keep writing if I have problems Thanks Matteo
Please, how is the correct way to apply the Yukon FE ram buffer initialization? I am using suse linux 10.1 (2.6.16.13-4) Thanks a lot!
Just to let you know that this appears to have fixed my problem too. Thanks Stephen! -manuj
The same for me. Everything works fine now. 02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8036 PCI-E Fast Ethernet Controller (rev 10) Will this patch be included in the next kernel?
Dear all, I still without apply the patch... Please somebody could write the steps to apply this patch? Thanks a lot! ----- Mensagem original ---- De: "bugme-daemon@bugzilla.kernel.org" <bugme-daemon@bugzilla.kernel.org> Para: euricovaz@yahoo.com.br Enviadas: Segunda-feira, 23 de Outubro de 2006 13:22:06 Assunto: [Bug 6839] sky2 transmitter lockup http://bugzilla.kernel.org/show_bug.cgi?id=6839 ------- Additional Comments From alex@maret.de 2006-10-23 10:09 ------- The same for me. Everything works fine now. 02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8036 PCI-E Fast Ethernet Controller (rev 10) Will this patch be included in the next kernel? ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. _______________________________________________________ O Yahoo! est
bugme-daemon@bugzilla.kernel.org ha scritto: > http://bugzilla.kernel.org/show_bug.cgi?id=6839 > > > > > > ------- Additional Comments From euricovaz@yahoo.com.br 2006-10-23 10:17 ------- > Dear all, > > I still without apply the patch... Please somebody could write the steps to apply this patch? > > Thanks a lot! > take the last vanilla kernel 2.6.18.1 source, now decompres it in a new directory; copy the patch to a file and apply it to the kernel sources with this command: cd newkerneldir cat kernelpatchfile | patch -p1 now u have to configure the kernel as u need and compile it .LP
About comment #58: Eurico, you use a e-mail .com.br, so I think that you is Brazilian. Link below show a how-to "Compile Kernel" in Pt-BR: <http://www.guiadohardware.net/www/tutoriais/100> To apply patch, you need this: #patch -p1 < sky2.patch Save the text available in <http://bugzilla.kernel.org/attachment.cgi?id=9313&action=view> how a patch file (e.g. sky2.patch) and save in /usr/src/linux-2.6.18.1 Bet regards, Renato S. Yamane
The patch worked fine to me!! Thanks a lot! ----- Mensagem original ---- De: "bugme-daemon@bugzilla.kernel.org" <bugme-daemon@bugzilla.kernel.org> Para: euricovaz@yahoo.com.br Enviadas: Ter
What is the file I am suppose to patch, I can't seem to find it, did a big grep didnt find anything but a header file. # patch -p1 < sky2.patch --dry-run can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |--- linux-2.6.18.1.orig/drivers/net/sky2.c 2006-10-20 16:51:05.000000000 -0700 |+++ linux-2.6.18.1/drivers/net/sky2.c 2006-10-20 16:51:24.000000000 -0700 -------------------------- File to patch: Skip this patch? [y] n File to patch: /usr/src/linux/drivers/net/sky2.c /usr/src/linux/drivers/net/sky2.c: No such file or directory Skip this patch? [y] Skipping patch. 3 out of 3 hunks ignored
So I figured out the obvious, that I had no sky2.c.. and found it, but I got this.. # patch -p1 < sky2.patch --dry-run patching file drivers/net/sky2.c Hunk #1 FAILED at 690. Hunk #2 FAILED at 702. Hunk #3 FAILED at 1084. 3 out of 3 hunks FAILED -- saving rejects to file drivers/net/sky2.c.rej So I am not downloading sky driver from a valid source? Were do I get it?