Bug 6839

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?