[tulip] Linksys LNE100TX on PowerPC system works only in promiscuous mode?

[Donald Becker]

On 8 Mar 2001, Gregorio Gervasio Jr. wrote:

> >>>>> On Thu, 08 Mar 2001 08:29:17 -0500 (EST), Donald Becker <becker@scyld.com> said:
> 
> >> I'm running Linux v2.2.18 on a PowerPC and my Linksys LNE100TX
> >> card works only with the interface in promiscuous mode.  If
...
> d> What Ethernet station address is reported by 'ifconfig' ?
> ...
> d> It's helpful to provide the rest of the detection message.
> d> I see from the 'mii-diag' output that you are using an ADMtek
> d> transceiver, thus you must have a v4.1 card.
> 
> d> Please try the following change around line 710
> d> 	} else if (chip_idx == COMET) {
> d> 		/* No need to read the EEPROM. */
> d> -		put_unaligned(inl(ioaddr + 0xA4), (u32 *)dev->dev_addr);
> d> -		put_unaligned(inl(ioaddr + 0xA8), (u16 *)(dev->dev_addr + 4));
> d> +		put_unaligned(le32_to_cpu(inl(ioaddr + 0xA4)),
> d> 				(u32 *)dev->dev_addr);
> d> 		put_unaligned(le16_to_cpu(inl(ioaddr + 0xA8)),
> d> 				(u16 *)(dev->dev_addr + 4));
> d> 		for (i = 0; i < 6; i ++)
> d> 			sum += dev->dev_addr[i];

Doh!

First, note that there are two modified statements (four new lines)
above.  I wrote it as if there was only one replacement line.

>         Looks like this code only gets executed the first time after
> power-up (not even after a reboot with no power-down)?  Anyway, here's
> what I got:

Correct.  You must cold-power-off the machine to test these changes.

> eth1: ADMtek Centaur-P rev 17 at 0xd0831000, 12:78:20:00:C8:BF, IRQ 24. 
...
> eth1: ADMtek Centaur-P rev 17 at 0xd0831000, 00:20:78:12:BF:C8, IRQ 24.

Ahhhh, that's much beter.  The correct Linksys prefix is 00:20:78
Now the issue is correctly handling the last two bytes of the address.

> 3. after "rmmod tulip" and re-enabling the interface:
> 
> tulip.c:v0.92t 1/15/2001  Written by Donald Becker <becker@scyld.com> 
>   http://www.scyld.com/network/tulip.html 
> eth1: ADMtek Centaur-P rev 17 at 0xd0835000, 00:20:78:12:00:00, IRQ 24. 
....
> The address changed but it started working.  Does that make sense?

Yup, we word-swapped the value when writing it back to the register.
But this had the beneficial effect of clearing all of the bits, so it
didn't matter which byte went where.

>         Does that help?  I added some print statements and after
> power-up, the contents of these locations are:
> 
> ioaddr + 0xA4 = 0x12782000
> ioaddr + 0xA8 = 0xffffc8bf

Lets try fixing line 1460
    if (tp->flags & MC_HASH_ONLY) {
	u32 addr_low = cpu_to_le32(get_unaligned((u32 *)dev->dev_addr));
-	u32 addr_high = cpu_to_le32(get_unaligned((u16 *)(dev->dev_addr+4)));
+	u32 addr_high = cpu_to_le16(get_unaligned((u16 *)(dev->dev_addr+4)));
	

Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993