Re: 64bit build of tulip driver
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.
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, 0x, 0x000b, 0x8f01, 0x0103, 0x0300, 0x0821, 0x000, 0x0001, 0x, 0x01e1 }
},
+ {"Cobalt Microserver", 0, 0x10, 0xE0, {0x1e00, /* 0 == controller #, 1e == offset */
+ 0x, /* 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 */
+ 0x, /* Drive GP0 Low (RST is active low) */
+ 0x0800, /* control mode, GP0 input (undriven) */
+ 0x, /* 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 */
+ 0x, /* 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 & 0xFFEF, ioaddr + CSR9);
- value = (phy_id << 21) | (location << 16) | 0x8000;
+ value = (phy_id << 21) | (location << 16) | 0x0800;
iowrite32(value, ioaddr + CSR10);
while(--i > 0) {
@@ -166,7 +168,7 @@
value = ioread32(ioaddr + CSR9);
iowrite32(value & 0xFFEF, ioaddr + CSR9);
- value = (phy_id << 21) | (location << 16) | 0x4000 | (val & 0x);
+ value = (phy_id << 21) | (location << 16) | 0x0400 | (val & 0x);
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"
Re: 64bit build of tulip driver
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
Grant, Thank you, I took your driver as a reference and added in the cobalt specifics to the eeprom.c file, works perfectly now. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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
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 > > :00:07.0: tulip_stop_rxtx() failed (CSR5 0xf066 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 :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 b0001400, > 00:10:E0:00:32:DE, IRQ 19. > PCI: Enabling device :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 b0001480, > 00:10:E0:00:32:DF, IRQ 20. > > > -- > > Jim Gifford > [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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 :00:07.0: tulip_stop_rxtx() failed (CSR5 0xf066 CSR6 0xb3862002) :00:07.0: tulip_stop_rxtx() failed (CSR5 0xf066 CSR6 0xb3862002) :00:07.0: tulip_stop_rxtx() failed (CSR5 0xf066 CSR6 0xb3862002) :00:07.0: tulip_stop_rxtx() failed (CSR5 0xf066 CSR6 0xb3862002) :00:07.0: tulip_stop_rxtx() failed (CSR5 0xf066 CSR6 0xb3862002) :00:07.0: tulip_stop_rxtx() failed (CSR5 0xf066 CSR6 0xb3862002) :00:07.0: tulip_stop_rxtx() failed (CSR5 0xf066 CSR6 0xb3862002) :00:07.0: tulip_stop_rxtx() failed (CSR5 0xf066 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 :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 b0001400, 00:10:E0:00:32:DE, IRQ 19. PCI: Enabling device :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 b0001480, 00:10:E0:00:32:DF, IRQ 20. -- Jim Gifford [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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 > :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 :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 > b0001400, 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 :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 > b0001480, 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 :00:07.0: tulip_stop_rxtx() failed > Dec 31 16:01:38 lfs :00:07.0: tulip_stop_rxtx() failed > Dec 31 16:01:44 lfs :00:07.0: tulip_stop_rxtx() failed > Dec 31 16:01:50 lfs :00:07.0: tulip_stop_rxtx() failed > Dec 31 16:01:56 lfs :00:07.0: tulip_stop_rxtx() failed > Dec 31 16:02:02 lfs :00:07.0: tulip_stop_rxtx() failed > Dec 31 16:02:08 lfs :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 :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 b
64bit build of tulip driver
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 :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 :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 b0001400, 00:10:E0:00:32:DE, IRQ 19. Dec 31 16:01:29 lfs PCI: Enabling device :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 b0001480, 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 :00:07.0: tulip_stop_rxtx() failed Dec 31 16:01:38 lfs :00:07.0: tulip_stop_rxtx() failed Dec 31 16:01:44 lfs :00:07.0: tulip_stop_rxtx() failed Dec 31 16:01:50 lfs :00:07.0: tulip_stop_rxtx() failed Dec 31 16:01:56 lfs :00:07.0: tulip_stop_rxtx() failed Dec 31 16:02:02 lfs :00:07.0: tulip_stop_rxtx() failed Dec 31 16:02:08 lfs :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 :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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
