Bug 5839 - uli526x partially recognizing interface
Summary: uli526x partially recognizing interface
Alias: None
Product: Drivers
Classification: Unclassified
Component: Network (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Grant Grundler
Depends on:
Reported: 2006-01-05 15:25 UTC by Quentin Decavel
Modified: 2008-02-17 10:38 UTC (History)
8 users (show)

See Also:
Kernel Version: 2.6.15
Tree: Mainline
Regression: ---

2.6.23 uli526x poll phy reset patch (1.18 KB, text/plain)
2007-09-01 16:13 UTC, Grant Grundler

Description Quentin Decavel 2006-01-05 15:25:46 UTC
Most recent kernel where this bug did not occur: 2.6.15 from kernel.org
Distribution: Debian Sarge 3.1
Hardware Environment: AMD Turion 64 ML 32
Software Environment:
Problem Description: uli526x loaded as module detects the eth0 interface, but
ifconfig complains that the cable is not plugged (even if it is) and thus eth0
cannot be correctly configured

relevant line from lspci:
0000:00:1b.0 Ethernet controller: ALi Corporation: Unknown device 5263 (rev 50)

dmesg | grep eth0:
eth0: ULi 5263 at pci:0000:00:1b.0, 00:40:d0:7f:c6:d8, irq 17
ADDRCONF(NETDEV_UP): eth0: link is not ready
ADDRCONF(NETDEV_UP): eth0: link is not ready
uli526x: eth0 NIC Link is Down

Steps to reproduce: boot kernel 2.6.15, then dhclient eth0
Comment 1 Harri Pitk 2006-01-13 05:36:33 UTC
I have the same problem with uli526x and kernel version 2.6.15: 
eth0: ULi M5263 at pci0000:00:0d.0, 00:13:d4:55:2c:36, irq 18. 
uli526x: eth0 NIC Link is Down 
This is an AMD Athlon 64 system, x86_64 kernel and lspci says 
0000:00:0d.0 Ethernet controller: ALi Corporation M5263 Ethernet Controller 
(rev 40) 
The controller works using the tulip driver in kernel 2.6.12, but only 
if I set the tulip module parameter "options=9" which forces the 
transceiver selection to MII 10baseT. In 2.6.15 the tulip driver no longer 
detects the controller at all. 
Note that here I am using a 10 Mbps half-duplex connection. Previously this 
controller was connected using a 100 Mbps full-duplex connection and then 
the uli526x in 2.6.15 actually did see that the link was up, but transmitting 
data was not possible until roughly one minute had passed after loading the 
driver. In that setup, tulip in 2.6.12 worked using "options=10". 
Comment 2 Hubert Verstraete 2006-01-19 04:40:08 UTC
Same problem with kernel 2.6.14 and 2.6.15 from Fedora Core 4 or Kanotix.
The motherboard is an Asrock 939Dual-SATA2 running with an AMD Athlon 64.
Comment 3 Zoltan FARKAS 2006-02-09 01:06:33 UTC
Same problem for me, Asrock 939Dual-SATA2.
After the driver is loaded, the link is down (cable is connected).
After doing an ('ifconfig eth0 down', wait 1-2 sec, 'ifconfig eth0 up', wait 1-2
sec) the link is up.
Comment 4 Zhuravlev Uriy 2006-03-02 16:22:33 UTC
This problemm ONLY 64 bit version kernel.
FATAL: Error inserting uli526x
(/lib/modules/2.6.15-gentoo-r5/kernel/drivers/net/tulip/uli526x.ko): Invalid

on 32bit kernel all ok.
Comment 5 Quentin Decavel 2006-04-07 14:06:33 UTC
Solved with kernel 2.6.16 (more precisely linux-2.6.16-gentoo-r1) with the amd
64-bits settings and gcc 3.4.6...
My thanks to the maintainers
Comment 6 Ulrich Klauer 2006-08-17 14:00:26 UTC
I still encounter this problem (as Quentin Decavel and Zoltan Farkas described
it) in kernel 2.6.17:
Linux version 2.6.17 (root@Knoppix) (gcc version 4.0.4 20060507 (prerelease)
(Debian 4.0.3-3)) #4 SMP PREEMPT Wed May 10 13:53:45 CEST 2006
I use an ASUS K8U-X mainboard with an AMD Sempron processor.
0000:00:0d.0 Ethernet controller: ALi Corporation M5263 Ethernet Controller (rev 40)
Comment 7 Harri Pitk 2007-01-13 09:19:23 UTC
This problem is still present in, with the same configuration as in 
comment 1.
Comment 8 Thomas R. (TRauMa) 2007-03-19 10:08:23 UTC
And still in Initial boot works, but /etc/init.d/net.eth0 restart
doesn't. Irritating.
Comment 9 Natalie Protasevich 2007-07-19 22:39:36 UTC
Is this still a problem with latest kernels? 
If this worked for some kernel level and then stopped - can someone try doing the git bisect please.
Comment 10 Harri Pitk 2007-07-19 23:27:34 UTC
What used to work was the old tulip driver until support for uli526x was removed from it (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ea8f400c98ec9ae0604bc5a6721174ef68635815)

The new uli526x driver has never worked for me. The latest kernel that I have tried was 2.6.20, I'll try 2.6.22 when I get back to the machine that has this problem (which will happen in early September).
Comment 11 Andrew Morton 2007-08-02 14:02:31 UTC
hi, Kyle ;)
Comment 12 David Rees 2007-08-21 22:11:03 UTC
FWIW, this is still an issue in Fedora kernel

I also have a K8U-X motherboard. lspci reports:
ALi Corporation ULi 1689,1573 integrated ethernet. (rev 40)
Comment 13 Grant Grundler 2007-08-30 10:30:23 UTC
Adding comments from kyle/Janne Huttunen email.

I'm pretty sure the basic problem is the same damn thing I fixed around 2002 for regular tulip with this patch:

And the same thing for 21142 init path a year or so later:

Kyle is already aware of this and Janne Huttunen (grrh....bugzilla won't let me add him to the CC list: jahuttun AT gmail com ) has volunteered to test a patch similar to the one posted at:

The above works for Janne.

Kyle, can you append a patch like we discussed (poll with udelay(100) 20 times max) to this bug that "just applies"?

My git fu is still pretty weak and it would be a PITA to generate on short notice. If not, I can provide one for linux- in the next couple of days (probably this weekend).

Comment 14 Harri Pitk 2007-08-31 05:07:59 UTC
I just checked that plain still has this bug, but applying patch from
fixes it completely for me. Thanks!
Comment 15 Grant Grundler 2007-09-01 16:13:24 UTC
Created attachment 12665 [details]
2.6.23 uli526x poll phy reset patch

can you test this patch also please?

If it works for you as well, kyle can push this upstream.

Comment 16 Harri Pitk 2007-09-02 00:28:29 UTC
I tested and yes, that one works too.
Comment 17 Grant Grundler 2007-09-02 12:56:31 UTC
Excellent - thanks.

Kyle (just added you to CC list for this bug),
Can you review/signoff the patch attached to this bug and push upstream?
It's just the loop we talked about in email.

Please let me know if I should submit myself or once you have, which kernel release it will go in (I'll add that to this bug and then close it).

Comment 18 Santiago Garcia Mantinan 2008-02-06 10:38:27 UTC
I'm pasting my message to lkml as Grant sugested, tested the patch that Grant has attached to this bug and seems to solve this problem for me as well.

Thanks a lot!

Original lkml mail:

Subject: uli526x doesn't get link if no link when interface is set up.

I've been experiencing problems with this (internal) card ever since I
bought this motherboard, lately I've been doing some tests and I found out
some things, maybe not enough to let us debug this, but I'll explain it just
in case.

The problem is that if the uli526x card is set up (ifconfig ethX up) when
there is no cable plugged or the cable is plugged to something that is off
at that time, this means, when there is no link for the card to detect,
then, when the cable or the switch or whatever is plugged, the link is not
detected by the uli526x card an thus no link is stablished (led on the
switch remains off).

This is the status reported by ethtool when the link should be on but the
driver is not detecting this condition and thus it is off:

        Supported ports: [ MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Advertised auto-negotiation: Yes
        Speed: Unknown! (65535)
        Duplex: Unknown! (255)
        Port: MII
        PHYAD: 1
        Transceiver: external
        Auto-negotiation: on
        Supports Wake-on: pg
        Wake-on: d
        Link detected: no

If at this time we run: "ifconfig ethX down" and after some time: "ifconfig
ethX up" then the link is detected, but if we run this two commands without
waiting a time between them, the link remains undetected.

In fact, if with an stablished and detected link, we run: "ifconfig ethX
down;ifconfig ethX up" the link is lost again and is not detected till we
run the two commands waiting some time between them.

Once the link is stablished if we don't touch the interface config (we don't
ifconfig it down) then we can unplug the cable or turn off the switch or
whatever and the card will detect the link whenever it becomes available

This makes me think that the problem is something related to the way on
which we are setting the card up.

I'm running 2.6.24 on a amd64 machine, these are the messages I get from the
driver on load:
uli526x: ULi M5261/M5263 net driver, version 0.9.3 (2005-7-29)
ACPI: PCI Interrupt 0000:00:12.0[A] -> GSI 20 (level, low) -> IRQ 20
eth1: ULi M5263 at pci0000:00:12.0, 00:13:8f:a7:af:b4, irq 20.
uli526x: eth1 NIC Link is Up 100 Mbps Full duplex

This is my lspci output:
00:12.0 0200: 10b9:5263 (rev 60)
        Subsystem: 1849:5263
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
+Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
+<TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 32 (5000ns min, 10000ns max), Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 20
        Region 0: I/O ports at c800 [size=256]
        Region 1: Memory at dedefc00 (32-bit, non-prefetchable) [size=256]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: uli526x
        Kernel modules: uli526x

I don't know what else to add but I offer myself to do all the wanted tests.
Comment 19 Santiago Garcia Mantinan 2008-02-17 01:40:29 UTC
As I have stated on the lkml the attached patch works ok and I think it should be applied to the 2.6.25-rc series.
Comment 20 Grant Grundler 2008-02-17 10:38:51 UTC
Thanks again!
I just submitted the patch to jgarzik/davem and netdev mailing list.
I see no reason this shouldn't go into 2.6.25.

Note You need to log in before you can comment on or make changes to this bug.