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". 

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.

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.

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
argument

on 32bit kernel all ok.
gcc4.1.

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

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)

This problem is still present in 2.6.19.2, with the same configuration as in 
comment 1.

And still in 2.6.20.3. Initial boot works, but /etc/init.d/net.eth0 restart
doesn't. Irritating.

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.
Thanks.

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).

hi, Kyle ;)

FWIW, this is still an issue in Fedora kernel 2.6.22.1-41.

I also have a K8U-X motherboard. lspci reports:
ALi Corporation ULi 1689,1573 integrated ethernet. (rev 40)

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:
    ftp://ftp.parisc-linux.org/patches/diff-tulip_phy_reset-03

And the same thing for 21142 init path a year or so later:
ftp://ftp.parisc-linux.org/patches/diff-2.6.12-rc3-tulip_21142_phyinit

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:
    http://lkml.org/lkml/2006/8/21/45

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-2.6.22.5 in the next couple of days (probably this weekend).

hth,
grant

I just checked that plain 2.6.22.6 still has this bug, but applying patch from
  http://lkml.org/lkml/2006/8/21/45
fixes it completely for me. Thanks!

Created attachment 12665 [details]
2.6.23 uli526x poll phy reset patch

Harri,
can you test this patch also please?

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

thanks,
grant

I tested and yes, that one works too.

Harri,
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).

thanks,
grant

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
again.

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
+PME(D0-,D1-,D2-,D3hot+,D3cold+)
                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.

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.

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.