Bug 420961

This was removed because it was known to cause data corruption issues.  It seems
this problem has been narrowed down a few specific motherboards.  The following
upstream patch has re-enabled that hardware.


commit 44a1d2e5c5c935fff3a093a1bcede32912c76421
Author: Stephen Hemminger <shemminger>
Date:   Mon Apr 30 14:23:49 2007 -0700

    sky2: re-enable 88E8056 for most motherboards

    This fixes the regression in 2.6.21 for users with 88e8056 on motherboard.
    Allow all but the Gigabyte motherboard has some unresolved bus problems.

    Signed-off-by: Stephen Hemminger <shemminger>
    Signed-off-by: Jeff Garzik <jeff>

Do you happen to use a Gigabyte motherboard?

No, it's ASUS P5B Deluxe MB

As far as I understand, everybody can add sky2 module in HIS OWN
modprobe.conf/blacklist file and disable it? 
I've seen bug about data corruption in gigabyte mb's, but never has such problem
with my ASUS P5B motherboard.
How I can enable this driver in my rpm-based kernel?

You should be able to do the following:

# modprobe sky2
# echo "11ab 4364" > /sys/bus/pci/drivers/sky2/new_id

and then you can test out the sky2 driver on your hardware and make sure it
still works well.  An additional ethernet device should now appear on your system.

I will also try and get the patch that enables this hardware added to me test
kernels soon so you can try it out there as well.

My test kernels have been updated to include a patch for this bugzilla.

http://people.redhat.com/agospoda/#rhel5

Please test them and report back your results.

This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".

Stanislav,

Have you tried any of my test kernels here:

http://people.redhat.com/agospoda/#rhel5

Does your card now work on this system?

Does this need more feedback, or can the needinfo be cancelled?

Bug is in NEEDINFO. Why is the Issue Tracker "Waiting on Tech"?

It appears the original reporter has not replied to my request for testing, but
someone did report it worked from the IT-attached ticket.

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

I've tested your kernel. Driver loads, says that everything is OK but in 1
second says that link is down.
I'm using "bonding" with active-backup mode.

Mar 17 08:39:31 SukholetSI kernel: bonding: bond0: Adding slave eth1.          
                                              
Mar 17 08:39:31 SukholetSI kernel: sky2 eth1: enabling interface               
                                              
Mar 17 08:39:31 SukholetSI kernel: sky2 eth1: ram buffer 0K                    
                                              
Mar 17 08:39:31 SukholetSI kernel: bonding: bond0: enslaving eth1 as a backup
interface with a down link.
Mar 17 08:39:31 SukholetSI kernel: sky2 eth1: Link is up at 100 Mbps, full
duplex, flow control rx
Mar 17 08:39:31 SukholetSI kernel: bonding: bond0: link status definitely up for
interface eth1.
Mar 17 08:39:31 SukholetSI kernel: bonding: bond0: making interface eth1 the new
active one.
Mar 17 08:39:31 SukholetSI kernel: bonding: bond0: first active interface up!  
                                              
Mar 17 08:39:31 SukholetSI kernel: skge eth0: Link is up at 1000 Mbps, full
duplex, flow control both
Mar 17 08:39:31 SukholetSI kernel: bonding: bond0: link status definitely up for
interface eth0.
Mar 17 08:39:31 SukholetSI kernel: bonding: bond0: making interface eth0 the new
active one.
Mar 17 08:39:31 SukholetSI kernel: sky2 eth1: Link is down.                    
                                              
Mar 17 08:39:31 SukholetSI kernel: bonding: bond0: link status definitely down
for interface eth1, disabling it
Mar 17 08:39:31 SukholetSI kernel: sky2 eth1: Link is up at 100 Mbps, full
duplex, flow control rx
Mar 17 08:39:31 SukholetSI kernel: bonding: bond0: link status definitely up for
interface eth1.
Mar 17 08:39:31 SukholetSI kernel: sky2 eth1: Link is down.
Mar 17 08:39:31 SukholetSI kernel: bonding: bond0: link status definitely down
for interface eth1, disabling it               
Mar 17 08:39:31 SukholetSI kernel: sky2 eth1: Link is up at 100 Mbps, full
duplex, flow control rx                            
Mar 17 08:39:31 SukholetSI kernel: bonding: bond0: link status definitely up for
interface eth1.                              
Mar 17 08:39:31 SukholetSI kernel: sky2 eth1: Link is down.                    
                                              
Mar 17 08:39:31 SukholetSI kernel: bonding: bond0: link status definitely down
for interface eth1, disabling it               
Mar 17 08:39:31 SukholetSI kernel: sky2 eth1: Link is up at 100 Mbps, full
duplex, flow control rx                            
Mar 17 08:39:31 SukholetSI kernel: bonding: bond0: link status definitely up for
interface eth1.                              
Mar 17 08:39:31 SukholetSI kernel: sky2 eth1: Link is down.                    
                                              
Mar 17 08:39:31 SukholetSI kernel: bonding: bond0: link status definitely down
for interface eth1, disabling it               
Mar 17 08:39:31 SukholetSI kernel: sky2 eth1: Link is up at 100 Mbps, full
duplex, flow control rx                            
Mar 17 08:39:31 SukholetSI kernel: bonding: bond0: link status definitely up for
interface eth1.
Mar 17 08:39:31 SukholetSI kernel: sky2 eth1: Link is down. 

Does the link continue to flap when not using bonding?

no, without bonding this card works just fine. 
Flood ping, large(>1G) ftp transfers (with binary compare of transferred files),
etc - everything is ok.

Can you post your bonding configuration (the contents of /etc/modprobe.conf)?

Also, please set the status to 'NEEDINFO -> Assignee' if you get test failures
-- FAILS_QA is typically used for test failures after the code has been
committed to our trees, so it doesn't apply for this case.

Thanks for the testing and quick feedback!

Sorry since this is rhel5 please post ifcfg-bond0 as well (since it's really the
proper place to configure bonding).

I'm sorry, there was a cryptic string in modprobe.conf, which makes such error
with bonding:

#install sky2 /sbin/modprobe --ignore-install sky2 || echo "11ab 4364" >
/sys/bus/pci/drivers/sky2/new_id

I've added this string to test sky2 with previous kernel.
So I've disabled it and everything is Ok (ping, large file transfers, bonding
NIC failover).

Just one thing remain to be fixed: This card have 2 LEDs - one for connectivity
(off, yellow for 100mbit and green for 1000) and one for activity. 

Unfortunately, connectivity always yellow even with gigabit connectivity and
activity blinks once when cable is plugged in and turns off later. This is quite
unconvinient.

Glad to hear bonding is working.  That LED problem does sound quite annoying. 
There is an LED management patch that is upstream that could be tried:

commit a84d0a3d6909c871bfa617a45a7517ce9292d4fb
Author: Stephen Hemminger <shemminger>
Date:   Fri Feb 22 16:00:33 2008 -0800

    sky2: fix LED management

    Fix problems in LED management, so ethtool -p works correctly on Yukon-EC
    and other chips. The driver was incorrectly setting the PHY LED overide bits.
    Moral: read the spec sheet, not the vendor driver.

I can try and add that to my test kernels and post here when they are available.

Will wait for new kernel and promise to test it 

My test kernels have been updated to include a patch for this bugzilla.

http://people.redhat.com/agospoda/#rhel5

Please test them and report back your results.

nothing changed, just as in previous version

Ok, thanks for the update.  

The LEDs seem to work find on my DLink DGE-560T, so can you tell me what card
you are using?

Sorry ignore my request in comment #26, I see in comment #1 that you are using
a 	88E8056 PCI-E Gigabit Ethernet Controller.

Just to confirm that your test kernel enables my 88E8056 controller again. I've
got a ShuttleXPC K45 barebones, with said controller.

Just wanted to let you know, as you requested on your page.

Thanks for the feedback.  Glad to hear it is working with the test kernel.  We
hope to include support for this hardware in our next update cycle (RHEL5.3).

ok. now I have time to test 2.6.18-94.el5.gtest.49
sky2 card is working fine "out of the box" BUT:
LED is broken. Activity LED blink once just when cable is plugged, all other
time is off. Network speed is always yellow, 100/1000 Mbps - without difference.

That is odd.  I have a PCIe-based sky2 card and I'll check out those LEDs to see
how they look.  Can you send me the PCI ID for that card (lspci output is fine)?

Ignore the request for PCI IDs -- I remember they are listed above.

in kernel-2.6.18-111.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2009-0225.html