Re: Sun GEM card looses TX on x86 32bit PCI

[Beezly <beezly@beezly.org.uk>]

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

Hi David,

This looks like it's working!

eth0      Link encap:Ethernet  HWaddr 00:03:BA:04:5B:D7
          inet addr:10.0.0.12  Bcast:10.0.0.255  Mask:255.255.255.0
          inet6 addr: fe80::203:baff:fe04:5bd7/10 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:623264 errors:0 dropped:4 overruns:4 frame:4
          TX packets:501679 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:864388119 (824.3 MiB)  TX bytes:719041874 (685.7 MiB)
          Interrupt:5 Base address:0x8400

There are a few dropped packets, and the card misses a few incoming
immediatly after a dropped packet although I guess this is it picking
itself up off the ground after RX has hung.

Also, regarding the missing MAC address on most architectures, I have it
on good authority that the last six digits of the MAC address are stored
in the Vital Product Data area on the PCI boards (presumably because the
first 6 are the "standard" SUN MAC prefix).

I had a quick fiddle around with pci_find_capability(<blah>,
PCI_CAP_ID_VPD), but it always returns NULL (i.e. no VPD). However, I've
also noticed that no-one appears to use that macro in any of the kernel
source. Is there another way to look at the VPD?

Many Thanks,

Beezly

On Tue, 2002-03-12 at 17:31, David S. Miller wrote:
>    From: Beezly <beezly@beezly.org.uk>
>    Date: 11 Mar 2002 22:51:42 +0000
> 
>    Ok, I've been fiddling around with the driver tonight and have managed
>    to get a little further by forcing the driver to do a full reset of the
>    chip when the RX buffer over flows. I achieved this by sticking a return
>    1; at the top of gem_rxmac_reset().
>    
>    I'm guessing this isn't an "optimal" reset for the situation but so far
>    it's having /reasonable/ results (i.e. I don't have to bring the
>    interface up and down every 30 seconds!).
>  ...   
>    Hope this helps,
> 
> I'll follow up on this and figure out why my RX reset code
> isn't working after I finish up some 2.5.x work.
> 
> But looking quickly I think I see what is wrong.  Please give
> this a try (and remember to remove your hacks before testing
> this :-):
> 
> --- drivers/net/sungem.c.~1~	Mon Mar 11 04:24:13 2002
> +++ drivers/net/sungem.c	Tue Mar 12 09:30:38 2002
> @@ -357,6 +357,7 @@ static int gem_rxmac_reset(struct gem *g
>  
>  		rxd->status_word = cpu_to_le64(RXDCTRL_FRESH(gp));
>  	}
> +	gp->rx_new = gp->rx_old = 0;
>  
>  	/* Now we must reprogram the rest of RX unit. */
>  	desc_dma = (u64) gp->gblock_dvma;


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]