This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Fri Apr 26 14:45:15 2024 Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by herbie.ucs.indiana.edu (8.7.5/8.6.12) with ESMTP id MAA23407 for ; Tue, 3 Dec 1996 12:12:09 -0500 (EST) Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <75028-7090>; Tue, 3 Dec 1996 19:10:29 +0200 Received: by vger.rutgers.edu id <213169-252>; Tue, 3 Dec 1996 12:02:07 -0500 From: Phillip Dillinger Date: Tue, 3 Dec 1996 08:49:36 -0800 Message-Id: <199612031649.IAA31185@luna.inside.sealabs.com> To: dupont@unantes.univ-nantes.fr, Jean-Francois.Micouleau@utc.fr Subject: Re: 3c59x.c Cc: linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk Jean-Francois Micouleau writes: > > On Wed, 27 Nov 1996, Phillip Dillinger wrote: > > Hi, > > > > Does anyone know about bus mastering on the 3com 3c59x or 3c900 cards? When > > I enable bus mastering in the driver, as opposed to PIO, the data rate > > delivered to the card goes way down. As far as I can see, the kernel is > > taking about 10ms waiting for the DMA to finish for each transfer. I have > > heard of other people getting close to 100Mbps on this card, but either due > > to my kernel, 2.0.23, or my hardware, a Fugu P100, the bus mastering does > > not seem to work right. > > you're not the only one having problems, on a busy ppro, I receive > ' eth0: Transmitter access conflict.' message 10 times every minute with > a 3c590, 8K vortex card. Sometimes the machine is totally hang on the > network side. The only solution is to ifconfig eth0 down and up to kick up > the 3c590. > > If anybody have clues ... Halas, I still have those problems with a 3c590. Tried ALL the drivers I Could find : 0.25 0.28C 0.28C-all 0.35 (the special boomerang one) And each time, after a week or so, the 3c590 stops working. As this machine is a NFS, NIS, Web & Proxy/Cache server, you can imagine the mess... I put a Ne2000 :-( in it for the moment.... I have a bunch of machines with 3c590, and there is only two which are gaving me problems. (all are 8k 3c590 cards). Those two machines are the more loaded machines. I haven't any ideas about what cause this problem. I'm wondering if the 3c590 parameters/optimizations (set by the 3c59xcfg.exe DOS program) can cause troubles ? -- Yann. -- _ _ ___ _________________________________ | | || . \ | Fac des sciences de Nantes. | \ /| | | _ | Tel : 40373069 / 40374945 | |_| |___/<_> | ydupont@sciences.univ-nantes.fr | --------------------------------- I have been playing around with the driver, and as it says, the TxAvailable interrupt from the card's FIFO is lost. And, the workaround does not work correctly. I have found something that kind of works, but I still can only get around 40Mbps in bus-mastering mode. Is anyone getting any more? Here is a patch from 0.28-all to my new driver: 17c17 < static char *version = "3c59x.c:v0.28c-all 9/22/96 becker@cesdis.gsfc.nasa.gov\n"; --- > static char *version = "3c59x-new.c:v0.28c-all 9/22/96 becker@cesdis.gsfc.nasa.gov\n"; 21a22 > #define REALLY_SLOW_IO 63,67d63 < #ifdef MODULE < #if !defined(CONFIG_MODVERSIONS) && !defined(__NO_VERSION__) < char kernel_version[] = UTS_RELEASE; < #endif < #else 72d67 < #endif 97c92 < #define VORTEX_DEBUG 2 --- > #define VORTEX_DEBUG 4 101c96 < #define WAIT_TX_AVAIL 200 --- > #define WAIT_TX_AVAIL 10 118c113 < int vortex_debug = 1; --- > int vortex_debug = 4; 353,373d347 < #ifdef MODULE < static int debug = -1; < /* A list of all installed Vortex devices, for removing the driver module. */ < static struct device *root_vortex_dev = NULL; < < int < init_module(void) < { < int cards_found; < < if (debug >= 0) < vortex_debug = debug; < if (vortex_debug) < printk(version); < < root_vortex_dev = NULL; < cards_found = vortex_scan(0); < return cards_found ? 0 : -ENODEV; < } < < #else 385d358 < #endif /* not MODULE */ 413d385 < #ifdef VORTEX_BUS_MASTER 429,436d400 < if (pci_latency != 255) { < printk(" 3Com EtherLink III: Overriding PCI latency" < " timer (CFLT) setting of %d, new value is 255.\n", < pci_latency); < pcibios_write_config_byte(pci_bus, pci_device_fn, < PCI_LATENCY_TIMER, 255); < } < #endif /* VORTEX_BUS_MASTER */ 482,511d445 < #ifdef MODULE < /* Allocate and fill new device structure. */ < int dev_size = sizeof(struct device) + < sizeof(struct vortex_private); < < dev = (struct device *) kmalloc(dev_size, GFP_KERNEL); < memset(dev, 0, dev_size); < dev->priv = ((void *)dev) + sizeof(struct device); < vp = (struct vortex_private *)dev->priv; < dev->name = vp->devname; /* An empty string. */ < dev->base_addr = ioaddr; < dev->irq = irq; < dev->init = vortex_probe1; < vp->product_name = product_names[product_index]; < vp->options = options; < if (options >= 0) { < vp->media_override = ((options & 7) == 2) ? 0 : options & 7; < vp->full_duplex = (options & 8) ? 1 : 0; < vp->bus_master = (options & 16) ? 1 : 0; < } else { < vp->media_override = 7; < vp->full_duplex = 0; < vp->bus_master = 0; < } < ether_setup(dev); < vp->next_module = root_vortex_dev; < root_vortex_dev = dev; < if (register_netdev(dev) != 0) < return -EIO; < #else /* not a MODULE */ 522,531c456,458 < if (options >= 0) { < vp->media_override = ((options & 7) == 2) ? 0 : options & 7; < vp->full_duplex = (options & 8) ? 1 : 0; < vp->bus_master = (options & 16) ? 1 : 0; < } else { < vp->media_override = 7; < vp->full_duplex = 0; < vp->bus_master = 0; < } < --- > vp->media_override = 7; > vp->full_duplex = 1; > vp->bus_master = 1; 533d459 < #endif /* MODULE */ 737,739d662 < #ifdef MODULE < MOD_INC_USE_COUNT; < #endif 836a760,765 > /* > This is a simple test to see why the same thing in the old driver does not > work. This actually only works a little, so it would be good to delete. > It purpose is to see if there is actually room in the FIFO to accept new > data. > */ 838c767,785 < /* Transmitter timeout, serious problems. */ --- > int i; > i=inw(ioaddr+TxFree); > SLOW_DOWN_IO; > SLOW_DOWN_IO; > SLOW_DOWN_IO; > SLOW_DOWN_IO; > SLOW_DOWN_IO; > if (i > skb->len) { > dev->tbusy=0; > goto start; > } > else { > printk("FIFO was full\n"); > return 1; > } > } > > if (dev->tbusy) { > /* Transmitter timeout, serious problems. */ 842,847d788 < if (tickssofar < 2) /* We probably aren't empty. */ < return 1; < /* Wait a while to see if there really is room. */ < for (i = WAIT_TX_AVAIL; i >= 0; i--) < if (inw(ioaddr + TxFree) > skb->len) < break; 866a808 > start: 877d818 < #ifdef VORTEX_BUS_MASTER 879a821,822 > SLOW_DOWN_IO; /* Fixes a timing problem */ > SLOW_DOWN_IO; 895,904d837 < #else < /* ... and the packet rounded to a doubleword. */ < outsl(ioaddr + TX_FIFO, skb->data, (skb->len + 3) >> 2); < dev_kfree_skb (skb, FREE_WRITE); < if (inw(ioaddr + TxFree) > 1536) { < dev->tbusy = 0; < } else < /* Interrupt us when the FIFO has room for max-sized packet. */ < outw(SetTxThreshold + (1536>>2), ioaddr + EL3_CMD); < #endif /* bus master */ 913c846 < while (--i > 0 && (tx_status = inb(ioaddr + TxStatus)) > 0) { --- > while (--i > 0 && (tx_status = inb(ioaddr + TxStatus)) > 0) { 986,987c919 < if (vortex_debug > 5) < printk(" TX room bit was handled.\n"); --- > printk(" TX room bit was handled.\n"); 989a922,923 > /* Set Tx Available Threshold to 1536 bytes */ > outw(SetTxThreshold,ioaddr + EL3_CMD); 993d926 < #ifdef VORTEX_BUS_MASTER 994a928,929 > SLOW_DOWN_IO; /* Fixes a timing problem */ > SLOW_DOWN_IO; 1000d934 < #endif 1007c941 < if (status & StatsFull) { /* Empty statistics. */ --- > if (status & StatsFull) { 1167,1169d1100 < #ifdef MODULE < MOD_DEC_USE_COUNT; < #endif 1271,1289d1201 < < #ifdef MODULE < void < cleanup_module(void) < { < struct device *next_dev; < < /* No need to check MOD_IN_USE, as sys_delete_module() checks. */ < while (root_vortex_dev) { < next_dev = ((struct vortex_private *)root_vortex_dev->priv)->next_module; < unregister_netdev(root_vortex_dev); < outw(TotalReset, root_vortex_dev->base_addr + EL3_CMD); < release_region(root_vortex_dev->base_addr, VORTEX_TOTAL_SIZE); < kfree(root_vortex_dev); < root_vortex_dev = next_dev; < } < } < #endif /* MODULE */ < It is a work-in-progress, but it fixes these problems: 1. A timing problem dealing with bus-mastered transmission. The SLOW_DOWN_IOs take care of that problem. 2. As per the manual, the PCI Latency timer does not need to be set to 0xff if bit 5 in the "Software Information 2" byte is set. In my cards it is set, so I removed that part. also, I took out some #ifdefs to make it easier for me to edit, and I made it always bus-mastering and full duplex. Here are some other things I am doing right now: 1. Bus-mastering recieves. 2. Fixing the TxAvailable bug, possible solutions are to change the interrupt mask, and to detect if the FIFO is not full at the end of transmission. 3. Getting the queue layer to fill the FIFO up to capacity, now it only fills to about 3600 bytes free. Any help would be greatly appreciated, and if possible, could anyone using 100Mbps tell me what your data rate is and what the contents of your Internal config register is at bootup. Phillip Dillinger phillip.dillinger@sealabs.com