64bit build of tulip driver

64bit build of tulip driver

[Jim Gifford]

Under 32bit the tulip driver works fine, but under 64 bit it gives me a 
lot if problems. I updated the tulip
to what is in the current repository, and the issue still exists. Any 
suggestions.

First off it continually sends data out the network interface and never 
negotiates is speed and duplex.
Second in the log files all I see is an uninformative message 
0000:00:07.0: tulip_stop_rxtx() failed

Here is all the bootup information differences I can find on the driver
64 bit
Dec 31 16:01:29 lfs tulip0: ***WARNING***: No MII transceiver found!
Dec 31 16:01:29 lfs tulip1: ***WARNING***: No MII transceiver found!
32 bit
Dec 31 16:01:16 lfs tulip0:  MII transceiver #1 config 1000 status 7809 
advertising 01e1
Dec 31 16:01:16 lfs tulip1:  MII transceiver #1 config 1000 status 7809 
advertising 01e1.

Complete boot log - yes I know the date and time are off.
Under a 64 bit compile
Dec 31 16:01:29 lfs Linux Tulip driver version 1.1.13 (May 11, 2002)
Dec 31 16:01:29 lfs PCI: Enabling device 0000:00:07.0 (0045 -> 0047)
Dec 31 16:01:29 lfs tulip0: Old format EEPROM on 'Cobalt Microserver' 
board.  Using substitute media control info.
Dec 31 16:01:29 lfs tulip0:  EEPROM default media type Autosense.
Dec 31 16:01:29 lfs tulip0:  Index #0 - Media MII (#11) described by a 
21142 MII PHY (3) block.
Dec 31 16:01:29 lfs tulip0: ***WARNING***: No MII transceiver found!
Dec 31 16:01:29 lfs eth0: Digital DS21143 Tulip rev 65 at 
ffffffffb0001400, 00:10:E0:00:32:DE, IRQ 19.
Dec 31 16:01:29 lfs PCI: Enabling device 0000:00:0c.0 (0005 -> 0007)
Dec 31 16:01:29 lfs tulip1: Old format EEPROM on 'Cobalt Microserver' 
board.  Using substitute media control info.
Dec 31 16:01:29 lfs tulip1:  EEPROM default media type Autosense.
Dec 31 16:01:29 lfs tulip1:  Index #0 - Media MII (#11) described by a 
21142 MII PHY (3) block.
Dec 31 16:01:29 lfs tulip1: ***WARNING***: No MII transceiver found!
Dec 31 16:01:29 lfs eth1: Digital DS21143 Tulip rev 65 at 
ffffffffb0001480, 00:10:E0:00:32:DF, IRQ 20.
Dec 31 16:01:29 lfs bootlog:  Bringing up the eth0 interface...[  OK  ]
Dec 31 16:01:30 lfs bootlog:  Adding IPv4 address 172.16.0.99 to the 
eth0 interface...[  OK  ]
Dec 31 16:01:31 lfs bootlog:  Setting up default gateway...[  OK  ]
Dec 31 16:01:32 lfs 0000:00:07.0: tulip_stop_rxtx() failed
Dec 31 16:01:38 lfs 0000:00:07.0: tulip_stop_rxtx() failed
Dec 31 16:01:44 lfs 0000:00:07.0: tulip_stop_rxtx() failed
Dec 31 16:01:50 lfs 0000:00:07.0: tulip_stop_rxtx() failed
Dec 31 16:01:56 lfs 0000:00:07.0: tulip_stop_rxtx() failed
Dec 31 16:02:02 lfs 0000:00:07.0: tulip_stop_rxtx() failed
Dec 31 16:02:08 lfs 0000:00:07.0: tulip_stop_rxtx() failed

Under 32 bit
Dec 31 16:01:16 lfs Linux Tulip driver version 1.1.13 (May 11, 2002)
Dec 31 16:01:16 lfs PCI: Enabling device 0000:00:07.0 (0045 -> 0047)
Dec 31 16:01:16 lfs tulip0: Old format EEPROM on 'Cobalt Microserver' 
board.  Using substitute media control info.
Dec 31 16:01:16 lfs tulip0:  EEPROM default media type Autosense.
Dec 31 16:01:16 lfs tulip0:  Index #0 - Media MII (#11) described by a 
21142 MII PHY (3) block.
Dec 31 16:01:16 lfs tulip0:  MII transceiver #1 config 1000 status 7809 
advertising 01e1.
Dec 31 16:01:16 lfs eth0: Digital DS21143 Tulip rev 65 at b0001400, 
00:10:E0:00:32:DE, IRQ 19.
Dec 31 16:01:16 lfs tulip1: Old format EEPROM on 'Cobalt Microserver' 
board.  Using substitute media control info.
Dec 31 16:01:16 lfs tulip1:  EEPROM default media type Autosense.
Dec 31 16:01:16 lfs tulip1:  Index #0 - Media MII (#11) described by a 
21142 MII PHY (3) block.
Dec 31 16:01:16 lfs tulip1:  MII transceiver #1 config 1000 status 7809 
advertising 01e1.
Dec 31 16:01:16 lfs eth1: Digital DS21143 Tulip rev 65 at b0001480, 
00:10:E0:00:32:DF, IRQ 20.
Dec 31 16:01:17 lfs bootlog:  Bringing up the eth0 interface...[  OK  ]
Dec 31 16:01:17 lfs bootlog:  Adding IPv4 address 172.16.0.99 to the 
eth0 interface...[  OK  ]
Dec 31 16:01:18 lfs bootlog:  Setting up default gateway...[  OK  ]
Dec 31 16:01:20 lfs eth0: Setting full-duplex based on MII#1 link 
partner capability of 45e1.

-- 
----
Jim Gifford
maillist@jg555.com

Re: 64bit build of tulip driver

[Grant Grundler]

On Wed, Mar 30, 2005 at 10:03:12AM -0800, Jim Gifford wrote:
> Under 32bit the tulip driver works fine, but under 64 bit it gives me a 
> lot if problems.

Sorry - I'm not seeing issues on either ia64 or parisc 64-bit systems.
But I'm only using HP 100BT cards (4-port, occasionally variants of
single port cards, and built-in on parisc workstations/servers).

2.6.12-rc1 bits seem to work fine on a500 (aka rp2470).


> I updated the tulip to what is in the current repository, and the issue
> still exists. Any suggestions.
> 
> First off it continually sends data out the network interface and never 
> negotiates is speed and duplex.
> Second in the log files all I see is an uninformative message 
> 0000:00:07.0: tulip_stop_rxtx() failed
> 
> Here is all the bootup information differences I can find on the driver

Are there any config option differences? 
e.g. MWI or MMIO options enabled on 64-bit but not 32-bit?

> 64 bit
> Dec 31 16:01:29 lfs tulip0: ***WARNING***: No MII transceiver found!
> Dec 31 16:01:29 lfs tulip1: ***WARNING***: No MII transceiver found!

You'll have to add printk's until you can sort out why the MII transceiver
isn't responding. Odds are 64-bit code runs faster than 32-bit on
the same machine (more registers or something).

> 32 bit
> Dec 31 16:01:16 lfs tulip0:  MII transceiver #1 config 1000 status 7809 
> advertising 01e1
> Dec 31 16:01:16 lfs tulip1:  MII transceiver #1 config 1000 status 7809 
> advertising 01e1.
> 
> Complete boot log - yes I know the date and time are off.
> Under a 64 bit compile
> Dec 31 16:01:29 lfs Linux Tulip driver version 1.1.13 (May 11, 2002)

Interesting My source tree says:
#define DRV_RELDATE     "December 15, 2004"
(same version # though)

> Dec 31 16:01:29 lfs PCI: Enabling device 0000:00:07.0 (0045 -> 0047)
> Dec 31 16:01:29 lfs tulip0: Old format EEPROM on 'Cobalt Microserver' 
> board.  Using substitute media control info.
> Dec 31 16:01:29 lfs tulip0:  EEPROM default media type Autosense.
> Dec 31 16:01:29 lfs tulip0:  Index #0 - Media MII (#11) described by a 
> 21142 MII PHY (3) block.
> Dec 31 16:01:29 lfs tulip0: ***WARNING***: No MII transceiver found!
> Dec 31 16:01:29 lfs eth0: Digital DS21143 Tulip rev 65 at 
> ffffffffb0001400, 00:10:E0:00:32:DE, IRQ 19.

HP is using exactly this chip. Difference seems to be with the phy/MII.

> Dec 31 16:01:29 lfs PCI: Enabling device 0000:00:0c.0 (0005 -> 0007)
> Dec 31 16:01:29 lfs tulip1: Old format EEPROM on 'Cobalt Microserver' 
> board.  Using substitute media control info.
> Dec 31 16:01:29 lfs tulip1:  EEPROM default media type Autosense.
> Dec 31 16:01:29 lfs tulip1:  Index #0 - Media MII (#11) described by a 
> 21142 MII PHY (3) block.
> Dec 31 16:01:29 lfs tulip1: ***WARNING***: No MII transceiver found!
> Dec 31 16:01:29 lfs eth1: Digital DS21143 Tulip rev 65 at 
> ffffffffb0001480, 00:10:E0:00:32:DF, IRQ 20.
> Dec 31 16:01:29 lfs bootlog:  Bringing up the eth0 interface...[  OK  ]
> Dec 31 16:01:30 lfs bootlog:  Adding IPv4 address 172.16.0.99 to the 
> eth0 interface...[  OK  ]
> Dec 31 16:01:31 lfs bootlog:  Setting up default gateway...[  OK  ]
> Dec 31 16:01:32 lfs 0000:00:07.0: tulip_stop_rxtx() failed
> Dec 31 16:01:38 lfs 0000:00:07.0: tulip_stop_rxtx() failed
> Dec 31 16:01:44 lfs 0000:00:07.0: tulip_stop_rxtx() failed
> Dec 31 16:01:50 lfs 0000:00:07.0: tulip_stop_rxtx() failed
> Dec 31 16:01:56 lfs 0000:00:07.0: tulip_stop_rxtx() failed
> Dec 31 16:02:02 lfs 0000:00:07.0: tulip_stop_rxtx() failed
> Dec 31 16:02:08 lfs 0000:00:07.0: tulip_stop_rxtx() failed

ISTR to remember submitting a patch so additional data
gets printed in tulip_stop_rxtx. Here is a reference to the patch
but I don't think it is relevant to the this problem:
	http://lkml.org/lkml/2004/12/15/119

grant

> Under 32 bit
> Dec 31 16:01:16 lfs Linux Tulip driver version 1.1.13 (May 11, 2002)
> Dec 31 16:01:16 lfs PCI: Enabling device 0000:00:07.0 (0045 -> 0047)
> Dec 31 16:01:16 lfs tulip0: Old format EEPROM on 'Cobalt Microserver' 
> board.  Using substitute media control info.
> Dec 31 16:01:16 lfs tulip0:  EEPROM default media type Autosense.
> Dec 31 16:01:16 lfs tulip0:  Index #0 - Media MII (#11) described by a 
> 21142 MII PHY (3) block.
> Dec 31 16:01:16 lfs tulip0:  MII transceiver #1 config 1000 status 7809 
> advertising 01e1.
> Dec 31 16:01:16 lfs eth0: Digital DS21143 Tulip rev 65 at b0001400, 
> 00:10:E0:00:32:DE, IRQ 19.
> Dec 31 16:01:16 lfs tulip1: Old format EEPROM on 'Cobalt Microserver' 
> board.  Using substitute media control info.
> Dec 31 16:01:16 lfs tulip1:  EEPROM default media type Autosense.
> Dec 31 16:01:16 lfs tulip1:  Index #0 - Media MII (#11) described by a 
> 21142 MII PHY (3) block.
> Dec 31 16:01:16 lfs tulip1:  MII transceiver #1 config 1000 status 7809 
> advertising 01e1.
> Dec 31 16:01:16 lfs eth1: Digital DS21143 Tulip rev 65 at b0001480, 
> 00:10:E0:00:32:DF, IRQ 20.
> Dec 31 16:01:17 lfs bootlog:  Bringing up the eth0 interface...[  OK  ]
> Dec 31 16:01:17 lfs bootlog:  Adding IPv4 address 172.16.0.99 to the 
> eth0 interface...[  OK  ]
> Dec 31 16:01:18 lfs bootlog:  Setting up default gateway...[  OK  ]
> Dec 31 16:01:20 lfs eth0: Setting full-duplex based on MII#1 link 
> partner capability of 45e1.
> 
> -- 
> ----
> Jim Gifford
> maillist@jg555.com
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: 64bit build of tulip driver

[Jim Gifford]

Grant
    Thanx for your feedback. I got it working, but I don't think the 
patch is the best. Here is the patch, and the information, but if you 
can recommend a different way to fix it, let me know. The patch was done 
by Peter Horton.
Here is the link to the full patch, 
http://ftp.jg555.com/patches/raq2/linux/linux-2.6.11.6-raq2_fix-2.patch
but here is the section for this issue
@@ -1628,6 +1631,16 @@
                 }
         }
 
+#if defined(CONFIG_MIPS_COBALT) && defined(CONFIG_MIPS64)
+        /*
+         * something very bad is happening. without this
+         * cache flush the PHY can't be read. I've tried
+         * various ins & outs, delays etc but only a call
+         * to printk or this flush seems to fix it ... help!
+         */
+        flush_cache_all();
+#endif
+
         /* Find the connected MII xcvrs.
            Doing this in open() would allow detecting external xcvrs
            later, but takes much time. */

>Are there any config option differences? 
>e.g. MWI or MMIO options enabled on 64-bit but not 32-bit?
>  
>
I verified that there are no differences.

>ISTR to remember submitting a patch so additional data
>gets printed in tulip_stop_rxtx. Here is a reference to the patch
>but I don't think it is relevant to the this problem:
>	http://lkml.org/lkml/2004/12/15/119
>
>  
>
Applied the patch, here is the output

0000:00:07.0: tulip_stop_rxtx() failed (CSR5 0xf0660000 CSR6 0xb3862002)
0000:00:07.0: tulip_stop_rxtx() failed (CSR5 0xf0660000 CSR6 0xb3862002)
0000:00:07.0: tulip_stop_rxtx() failed (CSR5 0xf0660000 CSR6 0xb3862002)
0000:00:07.0: tulip_stop_rxtx() failed (CSR5 0xf0660000 CSR6 0xb3862002)
0000:00:07.0: tulip_stop_rxtx() failed (CSR5 0xf0660000 CSR6 0xb3862002)
0000:00:07.0: tulip_stop_rxtx() failed (CSR5 0xf0660000 CSR6 0xb3862002)
0000:00:07.0: tulip_stop_rxtx() failed (CSR5 0xf0660000 CSR6 0xb3862002)
0000:00:07.0: tulip_stop_rxtx() failed (CSR5 0xf0660000 CSR6 0xb3862002)

I was able to get some more information on the bootup sequence with the 
updates.
Here is the output now from the driver

Linux Tulip driver version 1.1.13 (May 11, 2002)
PCI: Enabling device 0000:00:07.0 (0045 -> 0047)
tulip0: Old format EEPROM on 'Cobalt Microserver' board.  Using 
substitute media control info.
tulip0:  EEPROM default media type Autosense.
tulip0:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block.
tulip0: ***WARNING***: No MII transceiver found!
eth0: Digital DS21143 Tulip rev 65 at ffffffffb0001400, 
00:10:E0:00:32:DE, IRQ 19.
PCI: Enabling device 0000:00:0c.0 (0005 -> 0007)
tulip1: Old format EEPROM on 'Cobalt Microserver' board.  Using 
substitute media control info.
tulip1:  EEPROM default media type Autosense.
tulip1:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block.
tulip1: ***WARNING***: No MII transceiver found!
eth1: Digital DS21143 Tulip rev 65 at ffffffffb0001480, 
00:10:E0:00:32:DF, IRQ 20.


-- 
----
Jim Gifford
maillist@jg555.com

Re: 64bit build of tulip driver

[Grant Grundler]

On Thu, Mar 31, 2005 at 07:52:06PM -0800, Jim Gifford wrote:
> Grant
>    Thanx for your feedback. I got it working, but I don't think the 
> patch is the best. Here is the patch, and the information, but if you 
> can recommend a different way to fix it, let me know.

I can not "reccomend" one. I can suggest other things to try
since I'm very skeptical this patch will get accepted by
the maintainer (Jeff Garzik). He's normally wants a much
better explanation of the problem than "this works".


> The patch was done by Peter Horton.
> Here is the link to the full patch, 
> http://ftp.jg555.com/patches/raq2/linux/linux-2.6.11.6-raq2_fix-2.patch
> but here is the section for this issue

Jim,
You have other changes to tulip_core.c:
+                               /* Avoid a chip errata by prefixing a dummy entr
y. Don't do
+                                  this on the ULI526X as it triggers a differen
t problem */
....


Picking a few nits:
o comment extends past 80 columns - please wrap before 80 columns
o *Which* chip errata?
o *Which* other problem?
o I prefer diffs with "-p" when reviewing patches so I know which
  function is getting mangled.

-                       /* No media table either */
-                       tp->flags &= ~HAS_MEDIA_TABLE;
+                      /* Ensure our media table fixup get's applied */
+                      memcpy(ee_data + 16, ee_data, 8);

This isn't likely to get far either unless it's better explained.
You don't have to explain it to me, now. But have something handy
if you want jgarzik to accept it.


> @@ -1628,6 +1631,16 @@
>                 }
>         }
> 
> +#if defined(CONFIG_MIPS_COBALT) && defined(CONFIG_MIPS64)
> +        /*
> +         * something very bad is happening. without this
> +         * cache flush the PHY can't be read. I've tried
> +         * various ins & outs, delays etc but only a call
> +         * to printk or this flush seems to fix it ... help!
> +         */
> +        flush_cache_all();
> +#endif

The code immediately before this calls tulip_select_media().
Code paths exist in tulip_select_media() where the last thing the
driver does to the NIC is io_write(). This could easily be a posted
write flush problem. Does replacing flush_cache_all() with 
"ioread32(ioaddr + CSR12)" also work?

Can you find out how long one has to wait after banging
on CSR12 before it's safe to call tulip_find_mii()?

How long does flush_cache_all() take in microseconds?

It's possible this is a very fast PPC chip and it's executing the
code path between tulip_select_media() and tulip_find_mii()
faster than the chips can finish dealing with the writes to CSR12.
I'd consider this issue if flushing posted PCI writes doesn't help.

The tulip changes I maintain in parisc-linux port deal with
similar issues where the driver is not following the specified
timing requirements.
Search google for "tulip 802.3 22.2.4 Management functions"
or look into http://cvs.parisc-linux.org/linux-2.6/.


> +
>         /* Find the connected MII xcvrs.
>            Doing this in open() would allow detecting external xcvrs
>            later, but takes much time. */
> 
> >Are there any config option differences? 
> >e.g. MWI or MMIO options enabled on 64-bit but not 32-bit?
>
> I verified that there are no differences.

ok. thanks.

...
> Applied the patch, here is the output
> 
> 0000:00:07.0: tulip_stop_rxtx() failed (CSR5 0xf0660000 CSR6 0xb3862002)
...

Sorry, I don't have time to decode what these mean right now.
But I think the publicly available tulip chips docs sufficiently
explain what the registers mean and what state the chip is in.

> I was able to get some more information on the bootup sequence with the 
> updates.
> Here is the output now from the driver
> 
> Linux Tulip driver version 1.1.13 (May 11, 2002)
> PCI: Enabling device 0000:00:07.0 (0045 -> 0047)
> tulip0: Old format EEPROM on 'Cobalt Microserver' board.  Using 
> substitute media control info.
> tulip0:  EEPROM default media type Autosense.
> tulip0:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block.
> tulip0: ***WARNING***: No MII transceiver found!

ok. I assume this is unpatched.

thanks,
grant

> eth0: Digital DS21143 Tulip rev 65 at ffffffffb0001400, 
> 00:10:E0:00:32:DE, IRQ 19.
> PCI: Enabling device 0000:00:0c.0 (0005 -> 0007)
> tulip1: Old format EEPROM on 'Cobalt Microserver' board.  Using 
> substitute media control info.
> tulip1:  EEPROM default media type Autosense.
> tulip1:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block.
> tulip1: ***WARNING***: No MII transceiver found!
> eth1: Digital DS21143 Tulip rev 65 at ffffffffb0001480, 
> 00:10:E0:00:32:DF, IRQ 20.
> 
> 
> -- 
> ----
> Jim Gifford
> maillist@jg555.com

Re: 64bit build of tulip driver

[Grant Grundler]

On Fri, Apr 01, 2005 at 08:46:33AM -0800, Jim Gifford wrote:
> >Code paths exist in tulip_select_media() where the last thing the
> >driver does to the NIC is io_write(). This could easily be a posted
> >write flush problem. Does replacing flush_cache_all() with 
> >"ioread32(ioaddr + CSR12)" also work?
> >
> >The code immediately before this calls tulip_select_media().
> 
> Didn't work,

Can you try replacing flush_cache_all() with the following?
	ioread32(ioaddr + CSR12);
	udelay(500);	/* random delay until someone looks up what is spec'd */

>  I'm going to revert back and try your code and see if it 
> fixes the issue.

Erm...the code in parisc-linux tree won't have the COBALT hacks.
You might try adding selective bits from the parisc-linux tulip.


That fact the flush_cache_all() changes the behavior made me
wonder if IORESOURCE_CACHEABLE is set in the pci resource.
But that doesn't seem to matter for ppc (32 or 64).
Notes on what I learned below.

arch/ppc64/kernel/iomap.c doesn't look at that flag.
arch/ppc/kernel/io.c:pci_ioremap() has the nice comment:
	        if (flags & IORESOURCE_MEM)
                /* Not checking IORESOURCE_CACHEABLE because PPC does
                 * not currently distinguish between ioremap and
                 * ioremap_nocache. 
                 */
                return ioremap(start, len);

ioremap resolves to:
void __iomem *
ioremap64(unsigned long long addr, unsigned long size)
{
        return __ioremap(addr, size, _PAGE_NO_CACHE);
}

I *think* (too many ifdefs) ppc64 does the same in arch/ppc64/mm/init.c.
Cacheing is clear not an issue for accessing MMIO space via pci_iomap().

grant

Re: 64bit build of tulip driver

[Jim Gifford]

Grant,
    Thank you, I took your driver as a reference and added in the cobalt 
specifics to the eeprom.c file, works perfectly now.

Re: 64bit build of tulip driver

[Grant Grundler]

On Fri, Apr 01, 2005 at 12:23:25PM -0800, Jim Gifford wrote:
> Grant,
>    Thank you, I took your driver as a reference and added in the cobalt 
> specifics to the eeprom.c file, works perfectly now.

Cool! very welcome.

Can you do me a favor and submit a diff of all the tulip changes
you have at this point back to lkml (and whatever other lists are cc'd)?

jgarzik might accept your bits and ignore the parts that have been
submitted/rejected before.  But whatever you post will get archived
with this thread for others to find in the future.

thanks,
grant

Re: 64bit build of tulip driver

[Jim Gifford]

[-- Attachment #1: Type: text/plain, Size: 132 bytes --]

With Grant's help I was able to get the tulip driver to work with 64 bit 
MIPS.

Again Thanx Grant. Attached is the patch I used.



[-- Attachment #2: tulip-kernel[1].patch --]
[-- Type: text/x-diff, Size: 6226 bytes --]

diff -Naur linux-2.6.11.6/drivers/net/tulip/eeprom.c linux-2.6.11.6/drivers/net/tulip/eeprom.c
--- linux-2.6.11.6/drivers/net/tulip/eeprom.c	2005-03-25 19:28:37 -0800
+++ linux-2.6.11.6/drivers/net/tulip/eeprom.c	2005-04-01 09:13:39 -0800
@@ -63,6 +63,22 @@
 	 */
 	{ 0x1e00, 0x0000, 0x000b, 0x8f01, 0x0103, 0x0300, 0x0821, 0x000, 0x0001, 0x0000, 0x01e1 }
   },
+  {"Cobalt Microserver", 0, 0x10, 0xE0, {0x1e00, /* 0 == controller #, 1e == offset	*/
+					 0x0000, /* 0 == high offset, 0 == gap		*/
+					 0x0800, /* Default Autoselect			*/
+					 0x8001, /* 1 leaf, extended type, bogus len	*/
+					 0x0003, /* Type 3 (MII), PHY #0		*/
+					 0x0400, /* 0 init instr, 4 reset instr		*/
+					 0x0801, /* Set control mode, GP0 output	*/
+					 0x0000, /* Drive GP0 Low (RST is active low)	*/
+					 0x0800, /* control mode, GP0 input (undriven)	*/
+					 0x0000, /* clear control mode			*/
+					 0x7800, /* 100TX FDX + HDX, 10bT FDX + HDX	*/
+					 0x01e0, /* Advertise all above			*/
+					 0x5000, /* FDX all above			*/
+					 0x1800, /* Set fast TTM in 100bt modes		*/
+					 0x0000, /* PHY cannot be unplugged		*/
+  }},
   {NULL}};
 
 
diff -Naur linux-2.6.11.6/drivers/net/tulip/interrupt.c linux-2.6.11.6/drivers/net/tulip/interrupt.c
--- linux-2.6.11.6/drivers/net/tulip/interrupt.c	2005-03-25 19:28:40 -0800
+++ linux-2.6.11.6/drivers/net/tulip/interrupt.c	2005-04-01 08:59:41 -0800
@@ -26,7 +26,7 @@
 #define MIT_SIZE 15
 #define MIT_TABLE 15 /* We use 0 or max */
 
-unsigned int mit_table[MIT_SIZE+1] =
+static unsigned int mit_table[MIT_SIZE+1] =
 {
         /*  CRS11 21143 hardware Mitigation Control Interrupt
             We use only RX mitigation we other techniques for
diff -Naur linux-2.6.11.6/drivers/net/tulip/media.c linux-2.6.11.6/drivers/net/tulip/media.c
--- linux-2.6.11.6/drivers/net/tulip/media.c	2005-03-25 19:28:17 -0800
+++ linux-2.6.11.6/drivers/net/tulip/media.c	2005-04-01 08:57:20 -0800
@@ -44,8 +44,10 @@
 
 /* MII transceiver control section.
    Read and write the MII registers using software-generated serial
-   MDIO protocol.  See the MII specifications or DP83840A data sheet
-   for details. */
+   MDIO protocol.
+   See IEEE 802.3-2002.pdf (Section 2, Chapter "22.2.4 Management functions")
+   or DP83840A data sheet for more details.
+   */
 
 int tulip_mdio_read(struct net_device *dev, int phy_id, int location)
 {
@@ -88,7 +90,7 @@
 		value = ioread32(ioaddr + CSR9);
 		iowrite32(value & 0xFFEFFFFF, ioaddr + CSR9);
 		
-		value = (phy_id << 21) | (location << 16) | 0x80000000;
+		value = (phy_id << 21) | (location << 16) | 0x08000000;
 		iowrite32(value, ioaddr + CSR10);
 		
 		while(--i > 0) {
@@ -166,7 +168,7 @@
 		value = ioread32(ioaddr + CSR9);
 		iowrite32(value & 0xFFEFFFFF, ioaddr + CSR9);
 		
-		value = (phy_id << 21) | (location << 16) | 0x40000000 | (val & 0xFFFF);
+		value = (phy_id << 21) | (location << 16) | 0x04000000 | (val & 0xFFFF);
 		iowrite32(value, ioaddr + CSR10);
 		
 		while(--i > 0) {
@@ -307,13 +309,29 @@
 				int reset_length = p[2 + init_length];
 				misc_info = (u16*)(reset_sequence + reset_length);
 				if (startup) {
+					int timeout = 10;	/* max 1 ms */
 					iowrite32(mtable->csr12dir | 0x100, ioaddr + CSR12);
 					for (i = 0; i < reset_length; i++)
 						iowrite32(reset_sequence[i], ioaddr + CSR12);
+
+					/* flush posted writes */
+					ioread32(ioaddr + CSR12);
+
+					/* Sect 3.10.3 in DP83840A.pdf (p39) */
+					udelay(500);
+
+					/* Section 4.2 in DP83840A.pdf (p43) */
+					/* and IEEE 802.3 "22.2.4.1.1 Reset" */
+					while (timeout-- &&
+						(tulip_mdio_read (dev, phy_num, MII_BMCR) & BMCR_RESET))
+						udelay(100);
 				}
 				for (i = 0; i < init_length; i++)
 					iowrite32(init_sequence[i], ioaddr + CSR12);
+
+				ioread32(ioaddr + CSR12);	/* flush posted writes */
 			}
+
 			tmp_info = get_u16(&misc_info[1]);
 			if (tmp_info)
 				tp->advertising[phy_num] = tmp_info | 1;
diff -Naur linux-2.6.11.6/drivers/net/tulip/tulip.h linux-2.6.11.6/drivers/net/tulip/tulip.h
--- linux-2.6.11.6/drivers/net/tulip/tulip.h	2005-03-25 19:28:36 -0800
+++ linux-2.6.11.6/drivers/net/tulip/tulip.h	2005-04-01 09:01:07 -0800
@@ -475,8 +475,11 @@
 			udelay(10);
 
 		if (!i)
-			printk(KERN_DEBUG "%s: tulip_stop_rxtx() failed\n",
-					tp->pdev->slot_name);
+			printk(KERN_DEBUG "%s: tulip_stop_rxtx() failed"
+					" (CSR5 0x%x CSR6 0x%x)\n",
+					pci_name(tp->pdev),
+					ioread32(ioaddr + CSR5),
+					ioread32(ioaddr + CSR6));
 	}
 }
 
diff -Naur linux-2.6.11.6/drivers/net/tulip/tulip_core.c linux-2.6.11.6/drivers/net/tulip/tulip_core.c
--- linux-2.6.11.6/drivers/net/tulip/tulip_core.c	2005-03-25 19:28:22 -0800
+++ linux-2.6.11.6/drivers/net/tulip/tulip_core.c	2005-04-01 09:01:54 -0800
@@ -22,7 +22,7 @@
 #else
 #define DRV_VERSION	"1.1.13"
 #endif
-#define DRV_RELDATE	"May 11, 2002"
+#define DRV_RELDATE	"December 15, 2004"
 
 
 #include <linux/module.h>
@@ -1102,15 +1102,18 @@
 			entry = tp->cur_tx++ % TX_RING_SIZE;
 
 			if (entry != 0) {
-				/* Avoid a chip errata by prefixing a dummy entry. */
-				tp->tx_buffers[entry].skb = NULL;
-				tp->tx_buffers[entry].mapping = 0;
-				tp->tx_ring[entry].length =
-					(entry == TX_RING_SIZE-1) ? cpu_to_le32(DESC_RING_WRAP) : 0;
-				tp->tx_ring[entry].buffer1 = 0;
-				/* Must set DescOwned later to avoid race with chip */
-				dummy = entry;
-				entry = tp->cur_tx++ % TX_RING_SIZE;
+				/* Avoid a chip errata by prefixing a dummy entry. Don't do
+				   this on the ULI526X as it triggers a different problem */
+				if (!(tp->chip_id == ULI526X && (tp->revision = 0x40 || tp->revision == 0x50))) {
+					tp->tx_buffers[entry].skb = NULL;
+					tp->tx_buffers[entry].mapping = 0;
+					tp->tx_ring[entry].length =
+						(entry == TX_RING_SIZE-1) ? cpu_to_le32(DESC_RING_WRAP) : 0;
+					tp->tx_ring[entry].buffer1 = 0;
+					/* Must set DescOwned later to avoid race with chip */
+					dummy = entry;
+					entry = tp->cur_tx++ % TX_RING_SIZE;
+				}
 			}
 
 			tp->tx_buffers[entry].skb = NULL;
@@ -1749,7 +1752,7 @@
 
 #ifdef CONFIG_PM
 
-static int tulip_suspend (struct pci_dev *pdev, u32 state)
+static int tulip_suspend (struct pci_dev *pdev, pm_message_t state)
 {
 	struct net_device *dev = pci_get_drvdata(pdev);