From andrewm@uow.edu.au Mon, 01 Jan 2001 19:03:38 +1100 Date: Mon, 01 Jan 2001 19:03:38 +1100 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] 3c905CX things I've finally had a sane report back from a 905CX owner. It takes 32 milliseconds for the initial RxReset to complete. No other commands are reported as exceeding the 2,000 PCI cycles, however he wouldn't have exercised the other RxReset in vortex_error(). I'll be sticking with the udelay(10) busy loop for the while - it seems minimum risk. It _is_ safe to schedule() within vortex_up(). It's not safe to schedule() in vortex_probe() because of the probe/open race. So long-term, a schedule_timeout(1) is a better approach to handling the RxReset timer. The change to the MII scan order works fine. In fact, this is what 3com recommend in the 905C document: look at index 24 first. So I now have: for (phy = 0; phy < 32 && phy_idx < 1; phy++) { int mii_status, phyx; /* * For the 3c905CX we look at index 24 first, because it bogusly * reports an external PHY at all indices */ phyx = phy; if (phy == 0) phyx = 24; else if (phy == 24) phyx = 0; mii_status = mdio_read(dev, phyx, 1); Questions: 1: Why is vp->phys[] a two-char array? The driver never uses anything apart from phys[0]. 2: I'm including this code: /* Check the PCI latency value. On the 3c590 series the latency timer must be set to the maximum value to avoid data corruption that occurs when the timer expires during a transfer. This bug exists the Vortex chip only. */ pci_read_config_byte(pdev, PCI_LATENCY_TIMER, &pci_latency); if (pci_latency < new_latency) { printk(KERN_INFO "%s: Overriding PCI latency" " timer (CFLT) setting of %d, new value is %d.\n", dev->name, pci_latency, new_latency); pci_write_config_byte(pdev, PCI_LATENCY_TIMER, new_latency); } But this is currently done for all PCI devices. Shouldn't it only be done for IS_VORTEX devices? From becker@scyld.com Mon, 1 Jan 2001 11:42:39 -0500 (EST) Date: Mon, 1 Jan 2001 11:42:39 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [vortex] 3c905CX things On Mon, 1 Jan 2001, Andrew Morton wrote: > I've finally had a sane report back from a 905CX owner. It > takes 32 milliseconds for the initial RxReset to complete. You've found out that it does sometime take a long time to get accurate reports on new hardware. It is usually only very new users that have the latest hardware. 32 milliseconds likely means that some hardware designer just put in a bogus delay rather than do it correctly, just as some software people put in patch-up code rather than fixing a bug source. > Questions: > 1: Why is vp->phys[] a two-char array? The driver never uses anything > apart from phys[0]. It was to support cards with multiple transceivers, or an external MII connector. To my knowledge, 3Com hasn't produced any such card. An HomePNA card would be a likely product to use a second transceiver, but 3Com is just putting their name on Broadcom hardware. > 2: I'm including this code: > pci_read_config_byte(pdev, PCI_LATENCY_TIMER, &pci_latency); > if (pci_latency < new_latency) { ... > pci_write_config_byte(pdev, PCI_LATENCY_TIMER, new_latency); > > But this is currently done for all PCI devices. Shouldn't it > only be done for IS_VORTEX devices? Yes, this bug only exists on 3c590 (IS_VORTEX) chips. 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 From shawn.starr@home.net Mon, 01 Jan 2001 22:02:31 -0500 Date: Mon, 01 Jan 2001 22:02:31 -0500 From: Shawn Starr shawn.starr@home.net Subject: [vortex] 3C900B Serious Problems Ok, Im now trying Linux 2.4.0pre but this problem has happened with the original 2.2.x drivers as well. I will explain the problem: In the 2.4.0pre drivers, I get: eth0 Link encap:Ethernet HWaddr 00:50:DA:80:B5:74 inet addr:24.68.61.66 Bcast:24.68.61.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1712 errors:244 dropped:0 overruns:0 frame:340 TX packets:1854 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:9 Base address:0xe880 Now, with the 3COM made drivers for the 3C900B. I have not had any errors, collisisons or framing errors. 3Com 3c90x Version 1.0.0d 1999 <-- the current driver i use in 2.2.18 These work perfectly without issues. --------- the 3c59x drivers do not seem to want to detect my card properly. It is not: eth0: 3Com PCI 3c900 Cyclone 10Mbps TPO at 0xe880, 00:50:da:80:b5:74, IRQ 9 <-- IS NOT right This card is a 3C900B PCI EtherLink 10 PCI Adapter: 3c900B-TPO EtherLink 10 PCI TPO (I think `Hurricane' is the codename). Does the current 2.2/2.4 driver that comes with Linux support this card? If so, why am I getting these errors? I have tried using: insmod options=0x200 full_duplex=0 (off) and yet I still get these errors, not only that. But its still using autonegotiation which does not seem to work properly on this network (on @Home). Any suggestions? Thank you. Shawn Starr. From becker@scyld.com Tue, 2 Jan 2001 00:25:45 -0500 (EST) Date: Tue, 2 Jan 2001 00:25:45 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [vortex] 3C900B Serious Problems On Mon, 1 Jan 2001, Shawn Starr wrote: > Subject: [vortex] 3C900B Serious Problems > RX packets:1712 errors:244 dropped:0 overruns:0 frame:340 > TX packets:1854 errors:0 dropped:0 overruns:0 carrier:0 .. > the 3c59x drivers do not seem to want to detect my card properly. It is > not: > > eth0: 3Com PCI 3c900 Cyclone 10Mbps TPO at 0xe880, 00:50:da:80:b5:74, > IRQ 9 <-- IS NOT right > > This card is a 3C900B PCI EtherLink 10 PCI Adapter: > 3c900B-TPO EtherLink 10 PCI TPO (I think `Hurricane' is the > codename). I'll check the text string -- the reported name is not a problem. > Does the current 2.2/2.4 driver that comes with Linux support this > card? If so, why am I getting these errors? > > I have tried using: > > insmod options=0x200 full_duplex=0 (off) This is why -- you are forcing full duplex with the 0x200 setting. ( Note: Setting full_duplex=0 has no effect, the default is half duplex. The 0x200 will always set forced full duplex. ) 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 From shawn.starr@home.net Tue, 02 Jan 2001 08:13:52 -0500 Date: Tue, 02 Jan 2001 08:13:52 -0500 From: Shawn Starr shawn.starr@home.net Subject: [vortex] 3C900B Serious Problems How do i set the driver to use half-duplex? if 0x200 is full duplex at 10BaseT whats the bit to make it not full-duplex? There may be problems with the card trying to autonegotiate its media. When i try and manually insmod the driver it still insists on: Oct 15 11:10:35 (none) kernel: 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. How do i stop it from doing this? I want to basically force 10BaseT/half-duplex (or full) depending on what the driver allows. Donald Becker wrote: > On Mon, 1 Jan 2001, Shawn Starr wrote: > > > Subject: [vortex] 3C900B Serious Problems > > RX packets:1712 errors:244 dropped:0 overruns:0 frame:340 > > TX packets:1854 errors:0 dropped:0 overruns:0 carrier:0 > .. > > the 3c59x drivers do not seem to want to detect my card properly. It is > > not: > > > > eth0: 3Com PCI 3c900 Cyclone 10Mbps TPO at 0xe880, 00:50:da:80:b5:74, > > IRQ 9 <-- IS NOT right > > > > This card is a 3C900B PCI EtherLink 10 PCI Adapter: > > 3c900B-TPO EtherLink 10 PCI TPO (I think `Hurricane' is the > > codename). > > I'll check the text string -- the reported name is not a problem. > > > Does the current 2.2/2.4 driver that comes with Linux support this > > card? If so, why am I getting these errors? > > > > I have tried using: > > > > insmod options=0x200 full_duplex=0 (off) > > This is why -- you are forcing full duplex with the 0x200 setting. > > ( Note: Setting full_duplex=0 has no effect, the default is half duplex. > The 0x200 will always set forced full duplex. ) > > 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 From becker@scyld.com Tue, 2 Jan 2001 12:59:13 -0500 (EST) Date: Tue, 2 Jan 2001 12:59:13 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [vortex] 3C900B Serious Problems On Tue, 2 Jan 2001, Shawn Starr wrote: > How do i set the driver to use half-duplex? > if 0x200 is full duplex at 10BaseT Ethernet is half duplex by default, and thus the driver defaults to half duplex operation. > whats the bit to make it not full-duplex? The driver is always half duplex and > There may be problems with the card trying to autonegotiate its media. > When i try and manually insmod the driver it still insists on: > > Oct 15 11:10:35 (none) kernel: 8K byte-wide RAM 5:3 Rx:Tx split, > autoselect/Autonegotiate interface. > > How do i stop it from doing this? Stop it from doing what? 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 From shawn.starr@home.net Tue, 02 Jan 2001 14:16:27 -0500 Date: Tue, 02 Jan 2001 14:16:27 -0500 From: Shawn Starr shawn.starr@home.net Subject: [vortex] 3C900B Serious Problems #2 I want to MANUALLY tell the driver what kind of cabling im using (10BaseT). If its not autoselecting right, of cource im going to get errors. What arguments to i pass to the module (with the options=) to force the driver NOT to use autoselect/autonegotiate? If my LAN is not properly autonegotiating then the driver will assume that it is right. > > There may be problems with the card trying to autonegotiate its media. > > When i try and manually insmod the driver it still insists on: > > > > Oct 15 11:10:35 (none) kernel: 8K byte-wide RAM 5:3 Rx:Tx split, > > autoselect/Autonegotiate interface. > > > > How do i stop it from doing this? > > Stop it from doing what? > From becker@scyld.com Tue, 2 Jan 2001 22:50:17 -0500 (EST) Date: Tue, 2 Jan 2001 22:50:17 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [vortex] 3C900B Serious Problems On Tue, 2 Jan 2001, Shawn Starr wrote: > Fine, but now i get collisions when i have none before? > > RX packets:15022 errors:0 dropped:0 overruns:0 frame:0 > TX packets:7183 errors:0 dropped:0 overruns:0 carrier:0 > collisions:220 txqueuelen:100 Collisions are normal when you have a half duplex network. They do not indicate an error. > As i stated before, 3COM's driver doesnt give me any of these problems. > But they do not have a 2.4 release out (or will). 3Com's driver should also report collisions. 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 From matti.aarnio@zmailer.org Wed, 3 Jan 2001 15:11:41 +0200 Date: Wed, 3 Jan 2001 15:11:41 +0200 From: Matti Aarnio matti.aarnio@zmailer.org Subject: [vortex] MTU setting controls ? Hi, I need the card to support frames of larger than normal size, and ways to do it seem to be simple at least in case one has 3c905B (or latter) card. One way to do it is to supply global 'mtu' value of e.g. 1504, and let the existing code to handle the thing. However the way I did "ifconfig ethX mtu NNN" setting function below can only be described as questionable - it may cause card dysfunctionality when done in system where the interface is up (and under load?). (But it is the live time command which is questionable, doing this by setting ones ifcfg-eth0 with MTU=1504 cames up very reliably with desired MTU value -- I run 802.1Q VLAN tags on the card.) There really should be separate ways to set the actual maximum received packet size, and the interface-MTU -- I really would not like to tell to IP/TCP that the interface MTU is larger than 1500, so that I could receive VLAN tagged frames at the shared physical interface. Another issue with Vortex cards is that they don't seem to have multicast reception filter machinery, while *some* (newer) cards have working multicast filters, those have no need to blindly receive all multicasts! A generic network layer statistics thing is that there apparently is no counter for broadcasts, and multicasts and broadcasts do get folded into same counter. Partly this is interface problem, as we can't change the /proc/net/dev file format which has device counters on one long line for each interface. (I will raise this issue elsewere.) I really would like to know separately the received (and sent!) broadcasts and multicasts. /Matti Aarnio - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Changes done to 3c59x.c driver (my test machine has these) are "a bit" shaky -- the change_mtu() function clearly needs to poke at the card at selected moments, but it is *VERY* timing sensitive! Doing it at system startup with present code may get the system up just fine, or it may start spewing lots and lots of network card diagnostics to the console. (Doing "ifconfig vlan0123 mtu 3000" at active traffic interface is presently a surefire way to cause spewage.. Ball to driver specialists.) - There is vortex_set_mtu() -- actual register poking is questionable code in live system - Packet allocations are done with configured size variable, not with magic #define:d constant. diff -u -r linux-2400t10vl14/drivers/net/3c59x.c linux-2400t10vl14m/drivers/net/3c59x.c --- linux-2400t10vl14/drivers/net/3c59x.c Mon Oct 16 22:58:51 2000 +++ linux-2400t10vl14m/drivers/net/3c59x.c Sat Nov 4 00:33:32 2000 @@ -663,6 +663,7 @@ has_nway:1, open:1, must_free_region:1; /* Flag: if zero, Cardbus owns the I/O region */ + int pkt_buf_sz; /* MTU + 36 ??? (MAX_HEADER ?), plus alignment */ int drv_flags; u16 status_enable; u16 intr_enable; @@ -729,6 +730,7 @@ static int vortex_ioctl(struct net_device *dev, struct ifreq *rq, int cmd); static void vortex_tx_timeout(struct net_device *dev); static void acpi_set_WOL(struct net_device *dev); +static void wait_for_completion(struct net_device *, int); /* This driver uses 'options' to pass the media type, full-duplex flag, etc. */ /* Option count limit only -- unlimited interfaces are supported. */ @@ -777,6 +779,54 @@ } } +static int vortex_set_mtu(struct net_device *dev, int mtu) +{ + struct vortex_private *vp = dev->priv; + unsigned int old_mtu = dev->mtu; + + if (mtu < 68 || mtu > 4000) + return -EINVAL; /* FIXME: MODEL SPECIFIC LIMITATIONS ??? */ + + dev->mtu = mtu; + vp->pkt_buf_sz = mtu + 36; /* FIXME: What is this MAGIC 36 ??? */ + + /* Size transition under or above the magic 1500 byte marker. */ + + if ((old_mtu <= 1500 && mtu > 1500) || + (old_mtu > 1500 && mtu <= 1500)) { + + /* FIXME: IS THIS RACE SAFE ? DEADLOCK SAFE ? */ + + unsigned long flags; + long ioaddr = dev->base_addr; + unsigned int config; + + local_irq_save(flags); + + EL3WINDOW(3); + + /* Set the full-duplex bit. */ + config = (((vp->info1 & 0x8000) || vp->full_duplex ? 0x20 : 0) | + ((dev->mtu > 1500) ? 0x40 : 0) | + ((vp->full_duplex && vp->flow_ctrl && + vp->partner_flow_ctrl) ? 0x100 : 0)); + outw(config, ioaddr + Wn3_MAC_Ctrl); + + wait_for_completion(dev, TxReset); + wait_for_completion(dev, RxReset); + + outw(SetStatusEnb | 0x00, ioaddr + EL3_CMD); + + local_irq_restore(flags); + + if (vortex_debug > 0) + printk(KERN_DEBUG "%s: vortex_set_mtu() New mtu=%d Wn3MACCtrl=%4.4x.\n", + dev->name, mtu, config); + } + return mtu; +} + + /* returns count found (>= 0), or negative on error */ static int __init vortex_eisa_init (void) { @@ -881,6 +931,7 @@ dev->base_addr = ioaddr; dev->irq = irq; dev->mtu = mtu; + vp->pkt_buf_sz = mtu + 36; /* FIXME: What is this MAGIC 36 ??? */ vp->drv_flags = vci->drv_flags; vp->has_nway = (vci->drv_flags & HAS_NWAY) ? 1 : 0; vp->io_size = vci->io_size; @@ -1109,9 +1160,10 @@ dev->hard_start_xmit = vp->full_bus_master_tx ? boomerang_start_xmit : vortex_start_xmit; dev->stop = vortex_close; - dev->get_stats = vortex_get_stats; - dev->do_ioctl = vortex_ioctl; + dev->get_stats = vortex_get_stats; + dev->do_ioctl = vortex_ioctl; dev->set_multicast_list = set_rx_mode; + dev->change_mtu = vortex_set_mtu; dev->tx_timeout = vortex_tx_timeout; dev->watchdog_timeo = (watchdog * HZ) / 1000; @@ -1227,7 +1279,7 @@ /* Set the full-duplex bit. */ outw( ((vp->info1 & 0x8000) || vp->full_duplex ? 0x20 : 0) | - (dev->mtu > 1500 ? 0x40 : 0) | + ((dev->mtu > 1500) ? 0x40 : 0) | ((vp->full_duplex && vp->flow_ctrl && vp->partner_flow_ctrl) ? 0x100 : 0), ioaddr + Wn3_MAC_Ctrl); @@ -1298,7 +1350,7 @@ if (vp->full_bus_master_tx) { /* Boomerang bus master Tx. */ vp->cur_tx = vp->dirty_tx = 0; if (vp->drv_flags & IS_BOOMERANG) - outb(PKT_BUF_SZ>>8, ioaddr + TxFreeThreshold); /* Room for a packet. */ + outb(vp->pkt_buf_sz>>8, ioaddr + TxFreeThreshold); /* Room for a packet. */ /* Clear the Rx, Tx rings. */ for (i = 0; i < RX_RING_SIZE; i++) /* AKPM: this is done in vortex_open, too */ vp->rx_ring[i].status = 0; @@ -1354,14 +1406,14 @@ struct sk_buff *skb; vp->rx_ring[i].next = cpu_to_le32(vp->rx_ring_dma + sizeof(struct boom_rx_desc) * (i+1)); vp->rx_ring[i].status = 0; /* Clear complete bit. */ - vp->rx_ring[i].length = cpu_to_le32(PKT_BUF_SZ | LAST_FRAG); - skb = dev_alloc_skb(PKT_BUF_SZ); + vp->rx_ring[i].length = cpu_to_le32(vp->pkt_buf_sz | LAST_FRAG); + skb = dev_alloc_skb(vp->pkt_buf_sz); vp->rx_skbuff[i] = skb; if (skb == NULL) break; /* Bad news! */ skb->dev = dev; /* Mark as being used by this device. */ skb_reserve(skb, 2); /* Align IP on 16 byte boundaries */ - vp->rx_ring[i].addr = cpu_to_le32(pci_map_single(vp->pdev, skb->tail, PKT_BUF_SZ, PCI_DMA_FROMDEVICE)); + vp->rx_ring[i].addr = cpu_to_le32(pci_map_single(vp->pdev, skb->tail, vp->pkt_buf_sz, PCI_DMA_FROMDEVICE)); } if (i != RX_RING_SIZE) { int j; @@ -1443,12 +1495,15 @@ /* Set the full-duplex bit. */ EL3WINDOW(3); /* AKPM: this was missing from 2.3.99 3c59x.c! */ outw( (vp->full_duplex ? 0x20 : 0) | - (dev->mtu > 1500 ? 0x40 : 0) | + ((dev->mtu > 1500) ? 0x40 : 0) | ((vp->full_duplex && vp->flow_ctrl && vp->partner_flow_ctrl) ? 0x100 : 0), ioaddr + Wn3_MAC_Ctrl); if (vortex_debug > 1) printk(KERN_DEBUG "Setting duplex in Wn3_MAC_Ctrl\n"); /* AKPM: bug: should reset Tx and Rx after setting Duplex. Page 180 */ + + wait_for_completion(dev, TxReset); + wait_for_completion(dev, RxReset); } } } @@ -1558,7 +1613,7 @@ if (vp->tx_full) netif_stop_queue (dev); if (vp->drv_flags & IS_BOOMERANG) - outb(PKT_BUF_SZ>>8, ioaddr + TxFreeThreshold); + outb(vp->pkt_buf_sz>>8, ioaddr + TxFreeThreshold); outw(DownUnstall, ioaddr + EL3_CMD); } else { vp->stats.tx_dropped++; @@ -2053,10 +2108,19 @@ (pkt_len + 3) >> 2); } outw(RxDiscard, ioaddr + EL3_CMD); /* Pop top Rx packet. */ + + if (skb->data[0] & 1) { + /* Destination MAC address has at its first octet + the lowest bit set -> multicast or broadcast.. */ + if (memcmp(skb->data, dev->broadcast, ETH_ALEN) != 0) + /* Multicast! */ + vp->stats.multicast++; + } + skb->protocol = eth_type_trans(skb, dev); - netif_rx(skb); dev->last_rx = jiffies; vp->stats.rx_packets++; + netif_rx(skb); /* Wait a limited time to go to next packet. */ for (i = 200; i >= 0; i--) if ( ! (inw(ioaddr + EL3_STATUS) & CmdInProgress)) @@ -2114,7 +2178,7 @@ if (pkt_len < rx_copybreak && (skb = dev_alloc_skb(pkt_len + 2)) != 0) { skb->dev = dev; skb_reserve(skb, 2); /* Align IP on 16 byte boundaries */ - pci_dma_sync_single(vp->pdev, dma, PKT_BUF_SZ, PCI_DMA_FROMDEVICE); + pci_dma_sync_single(vp->pdev, dma, vp->pkt_buf_sz, PCI_DMA_FROMDEVICE); /* 'skb_put()' points to the start of sk_buff data area. */ memcpy(skb_put(skb, pkt_len), vp->rx_skbuff[entry]->tail, @@ -2125,9 +2189,18 @@ skb = vp->rx_skbuff[entry]; vp->rx_skbuff[entry] = NULL; skb_put(skb, pkt_len); - pci_unmap_single(vp->pdev, dma, PKT_BUF_SZ, PCI_DMA_FROMDEVICE); + pci_unmap_single(vp->pdev, dma, vp->pkt_buf_sz, PCI_DMA_FROMDEVICE); rx_nocopy++; } + + if (skb->data[0] & 1) { + /* Destination MAC address has at its first octet + the lowest bit set -> multicast or broadcast.. */ + if (memcmp(skb->data, dev->broadcast, ETH_ALEN) != 0) + /* Multicast! */ + vp->stats.multicast++; + } + skb->protocol = eth_type_trans(skb, dev); { /* Use hardware checksum info. */ int csum_bits = rx_status & 0xee000000; @@ -2138,9 +2211,9 @@ rx_csumhits++; } } - netif_rx(skb); dev->last_rx = jiffies; vp->stats.rx_packets++; + netif_rx(skb); } entry = (++vp->cur_rx) % RX_RING_SIZE; } @@ -2149,7 +2222,7 @@ struct sk_buff *skb; entry = vp->dirty_rx % RX_RING_SIZE; if (vp->rx_skbuff[entry] == NULL) { - skb = dev_alloc_skb(PKT_BUF_SZ); + skb = dev_alloc_skb(vp->pkt_buf_sz); if (skb == NULL) { static unsigned long last_jif; if ((jiffies - last_jif) > 10 * HZ) { @@ -2162,7 +2235,7 @@ } skb->dev = dev; /* Mark as being used by this device. */ skb_reserve(skb, 2); /* Align IP on 16 byte boundaries */ - vp->rx_ring[entry].addr = cpu_to_le32(pci_map_single(vp->pdev, skb->tail, PKT_BUF_SZ, PCI_DMA_FROMDEVICE)); + vp->rx_ring[entry].addr = cpu_to_le32(pci_map_single(vp->pdev, skb->tail, vp->pkt_buf_sz, PCI_DMA_FROMDEVICE)); vp->rx_skbuff[entry] = skb; } vp->rx_ring[entry].status = 0; /* Clear complete bit. */ @@ -2249,7 +2322,7 @@ for (i = 0; i < RX_RING_SIZE; i++) if (vp->rx_skbuff[i]) { pci_unmap_single( vp->pdev, le32_to_cpu(vp->rx_ring[i].addr), - PKT_BUF_SZ, PCI_DMA_FROMDEVICE); + vp->pkt_buf_sz, PCI_DMA_FROMDEVICE); dev_kfree_skb(vp->rx_skbuff[i]); vp->rx_skbuff[i] = 0; } @@ -2402,16 +2475,23 @@ static void set_rx_mode(struct net_device *dev) { long ioaddr = dev->base_addr; - int new_mode; + int new_mode = SetRxFilter | RxStation; + + if (dev->flags & IFF_BROADCAST) + new_mode |= RxBroadcast; if (dev->flags & IFF_PROMISC) { if (vortex_debug > 0) - printk(KERN_NOTICE "%s: Setting promiscuous mode.\n", dev->name); - new_mode = SetRxFilter|RxStation|RxMulticast|RxBroadcast|RxProm; - } else if ((dev->mc_list) || (dev->flags & IFF_ALLMULTI)) { - new_mode = SetRxFilter|RxStation|RxMulticast|RxBroadcast; - } else - new_mode = SetRxFilter | RxStation | RxBroadcast; + printk(KERN_NOTICE "%s: Setting promiscuous mode; cnt=%d\n", dev->name, dev->promiscuity); + new_mode |= RxProm; + } + + /* FIXME: Some of the 3c905 family cards actually have a WORKING + multicast reception filter, take it into use! */ + + if ((dev->mc_list) || (dev->flags & IFF_ALLMULTI)) { + new_mode |= RxMulticast; + } outw(new_mode, ioaddr + EL3_CMD); } From andrewm@uow.edu.au Thu, 04 Jan 2001 01:00:24 +1100 Date: Thu, 04 Jan 2001 01:00:24 +1100 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] MTU setting controls ? Matti Aarnio wrote: > > Hi, > > I need the card to support frames of larger than normal size, > and ways to do it seem to be simple at least in case one has 3c905B > (or latter) card. One way to do it is to supply global 'mtu' > value of e.g. 1504, and let the existing code to handle the thing. > I'd suggest simply failing the MTU change if the device is open. That way, vortex_up() will take care of lots of initialisation. Does that work OK? If you do: ifconfig eth0 down ifconfig eth0 mtu 2000 ifconfig eth0 up The 905C has a 256-slot multicast filter. 3com forgot to document the hashing algorithm, but there is an implementation in their 3c90x.c. I'd be interested in Donald's opinion on the overall idea. What's your timing on this? I have a small amount of stuff which needs to go into 2.4.0 for the 3c905CX. Then as soon as 2.4.1 hits the streets Alexey has a patch which adds scatter-gather for the fragmented SKBs which are part of the zerocopy-sendfile changes. I guess we could include this work in that changeset. From matti.aarnio@zmailer.org Wed, 3 Jan 2001 16:30:17 +0200 Date: Wed, 3 Jan 2001 16:30:17 +0200 From: Matti Aarnio matti.aarnio@zmailer.org Subject: [vortex] MTU setting controls ? On Thu, Jan 04, 2001 at 01:00:24AM +1100, Andrew Morton wrote: > Matti Aarnio wrote: > > Hi, > > > > I need the card to support frames of larger than normal size, > > and ways to do it seem to be simple at least in case one has 3c905B > > (or latter) card. One way to do it is to supply global 'mtu' > > value of e.g. 1504, and let the existing code to handle the thing. > > I'd suggest simply failing the MTU change if the device is open. > That way, vortex_up() will take care of lots of initialisation. > Does that work OK? If you do: > > ifconfig eth0 down > ifconfig eth0 mtu 2000 > ifconfig eth0 up Or even (during system boot, starting in 'down' state) ifconfig eth0 mtu 2000 up works just fine. > The 905C has a 256-slot multicast filter. 3com forgot to document > the hashing algorithm, but there is an implementation in their > 3c90x.c. > > I'd be interested in Donald's opinion on the overall idea. > > What's your timing on this? This century, preferred. 2.4.0 ? Not necessarily. If it would cause more wide-spread activity of implementing missing multicast filters for hardware supporting them, all the better. Oh, and writing the RX IP(v4) TCP/UDP checksum checking would be neat, too. (That is, copy it from 3Com driver ?) (Same story with intel.?) > I have a small amount of stuff which > needs to go into 2.4.0 for the 3c905CX. Then as soon as 2.4.1 > hits the streets Alexey has a patch which adds scatter-gather > for the fragmented SKBs which are part of the zerocopy-sendfile > changes. > > I guess we could include this work in that changeset. Especially if there is a way to receive "larger" frames without upping the *visible* mtu of the device (say, allow receiving up to magic 36 bytes of slack built in every receive buffer). I recall we had some talk about the issue about 1/2 year ago, and your (or Donald's?) opinnion was that as it could (sometimes) excercise unproven "oversize frame" error handling path, such change should not be added... The VLAN tag stuff works by receiving up to 1504 byte payloads from physical interface, and if there is 0x8100 for protocol type tag, then it is sent to VLAN processing, header is analyzed, and frame is diverted to correct VLAN interface. However the 802.1Q management traffic goes out on untagged frames via the basic physical interface, thus I have: - eth0 - eth0.vlan-nn - eth0.vlan-mm Each of those interfaces *should* have MTU 1500, but due to current technological limits, eth0 must now have 1504 as its *advertised* MTU. How can we change that ? It needs to receive 1504 byte sized frames, but should not claim such capability to IP PMTU machinery. Host-Eth -> Switch-Eth/Switch-Trunk -> eth0 -> eth0.vlan-nn 1500 1500 1504 1504 1500 /Matti Aarnio From becker@scyld.com Wed, 3 Jan 2001 16:29:52 -0500 (EST) Date: Wed, 3 Jan 2001 16:29:52 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [vortex] MTU setting controls ? On Wed, 3 Jan 2001, Matti Aarnio wrote: > I need the card to support frames of larger than normal size, ... > There really should be separate ways to set the actual maximum received > packet size, and the interface-MTU -- I really would not like to tell to > IP/TCP that the interface MTU is larger than 1500, so that I could receive > VLAN tagged frames at the shared physical interface. VLAN support is a special case with later 3c905 cards. The IP checksum hardware must understand VLAN headers, so there is explicit support for MTUs of 1500 and 1500+4. In addition most EL-XL cards support almost-FDDI size frames of about 4500 bytes. The FDDI-size enable is the current oversized-MTU bit being set bit 0x40 in Wn3_MAC_Ctrl > Another issue with Vortex cards is that they don't seem to have multicast > reception filter machinery, while *some* (newer) cards have working multicast > filters, those have no need to blindly receive all multicasts! Bonus: The early multicast filter implementation was conceptually broken. You didn't know which filter bits that you were writing. > A generic network layer statistics thing is that there apparently is no > counter for broadcasts, and multicasts and broadcasts do get folded into I'll respond to this with a longer letter. The essential point are I had a proposal about four years ago that added a bunch of new fields That proposal is still mostly valid. /proc/net/dev cannot be changed. I was unhappy when it was changed the last time: we are still getting "bug" reports broke, and it broke my carefully summarized fields that fit in 80 columns, but still didn't emit all of our existing counter values Statistics should be re-ordered to be cache line friendly. A driver should be able to get a statistics table in net_device, or at least register its private table, so that low-overhead access to approximate statistics is available. > - Changes done to 3c59x.c driver (my test machine has these) > are "a bit" shaky -- the change_mtu() function clearly needs > to poke at the card at selected moments, but it is *VERY* ... > Ball to driver specialists.) You should only be able to increase the Rx MTU past 1500 when an Ethernet device is down, assuming that you can change it to >1500 at all. Changing the Rx MTU requires shutting down the receiver and re-allocating all of the Rx buffers. This is just like changing the station address: if you have to shut down the card's receiver anyway, why add complexity into the driver? Just have the user-level code do the down+up. > - There is vortex_set_mtu() -- actual register poking is questionable > code in live system Switching to window 3 should be mostly OK, but you will need to hold the register window lock. > + vp->pkt_buf_sz = mtu + 36; /* FIXME: What is this MAGIC 36 ??? */ IMPORTANT DETAIL!! The Ethernet drivers try to always allocate 1536 (3*512) byte blocks. Most cards use slightly fewer bytes, but when you have two different card you don't want to mix up the allocation pool with two slightly different sizes (e.g. both 1520 and 1532 byte buffers). Typical Rx buffer sizes 1514 Basic maximum Ethernet packet size w/headers +4 Packet with 4 byte CRC +2 Align the IP header +16 Prepend a descriptor > + vp->pkt_buf_sz = mtu + 36; /* FIXME: What is this MAGIC 36 ??? */ This is hack to do vp->pkt_buf_sz = mtu < 1500 ? 1536 : round_up(mtu + 2); 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 From sumiya@ymg.urban.ne.jp Thu, 4 Jan 2001 21:21:20 +0900 Date: Thu, 4 Jan 2001 21:21:20 +0900 From: Etsuo SUMIYA sumiya@ymg.urban.ne.jp Subject: [vortex] 3C905B overrun error Hello! vortex@scyld.com users. $B!V(Byour message$B!W$K$F(B Etsuo SUMIYA $B$5$s(B: > Hello! I am setting up Linux firwall using 3c905B, NE2000 > clone and 3c509. 3C905B connected to a 100 MBPS hub. Linux It seems that my PC, Pentium 120 MHz Acer V50LA mother board, has no enough capability to run the 3C905B NIC by bus master trancefer. When I run the configuration tool bundled with the card, warring message said so. Thank you. -- Etsuo SUMIYA From larry@spack.org Thu, 4 Jan 2001 15:19:45 -0800 (PST) Date: Thu, 4 Jan 2001 15:19:45 -0800 (PST) From: Adam Shand larry@spack.org Subject: [vortex] problems with 2.2.18 / 3c556B driver hi. i have this problem on a thinkpad t20. the card works great until i suspend/resume. the only way i can find to fix it is to reboot (unloading and reloading the module does not work). a friend i work with also has a t20 and reloading the module works just fine for him (with the same kernel). both of us are running stock debian (woody) boxes. when it works on initial boot i get this when the module is loaded: Jan 4 14:58:55 heyzeus kernel: 3c59x.c 15Sep00 Donald Becker and others http://www.scyld.com/network/vortex.html Jan 4 14:58:55 heyzeus kernel: eth0: 3Com 3c556B Laptop Hurricane at 0x1800, 00:00:86:43:e9:b3, IRQ 11 Jan 4 14:58:55 heyzeus kernel: eth0: CardBus functions mapped e8101000->c8031000 (PCMCIA committee brain-damage). Jan 4 14:58:55 heyzeus kernel: 8K byte-wide RAM 5:3 Rx:Tx split, MII interface. Jan 4 14:58:55 heyzeus kernel: MII transceiver found at address 0, status 7869. Jan 4 14:58:55 heyzeus kernel: Enabling bus-master transmits and whole-frame receives. after a suspend/resume cycle i get this when the module is loaded: Jan 4 14:55:12 heyzeus kernel: 3c59x.c 15Sep00 Donald Becker and others http://www.scyld.com/network/vortex.html Jan 4 14:55:12 heyzeus kernel: eth0: 3Com 3c556B Laptop Hurricane at 0x1800, ff:ff:ff:ff:ff:ff, IRQ 11 Jan 4 14:55:12 heyzeus kernel: eth0: CardBus functions mapped 00000000->00000000 (PCMCIA committee brain-damage). Jan 4 14:55:12 heyzeus kernel: 1024K word-wide RAM 3:5 Rx:Tx split, autoselect/ interface. Jan 4 14:55:12 heyzeus kernel: Enabling bus-master transmits and early receives. Jan 4 14:56:08 heyzeus kernel: Flags; bus-master 1, full 0; dirty 16 current 16. and then after a while this repeats over and over ... Jan 4 14:56:08 heyzeus kernel: Transmit list ffffffff vs. c7a63200. Jan 4 14:56:08 heyzeus kernel: 0: @c7a63200 length 8000002a status 0000002a Jan 4 14:56:08 heyzeus kernel: 1: @c7a63210 length 8000002a status 0000002a Jan 4 14:56:08 heyzeus kernel: 2: @c7a63220 length 8000002a status 0000002a Jan 4 14:56:08 heyzeus kernel: 3: @c7a63230 length 8000002a status 0000002a Jan 4 14:56:08 heyzeus kernel: 4: @c7a63240 length 8000002a status 0000002a Jan 4 14:56:08 heyzeus kernel: 5: @c7a63250 length 8000002a status 0000002a Jan 4 14:56:08 heyzeus kernel: 6: @c7a63260 length 8000002a status 0000002a Jan 4 14:56:08 heyzeus kernel: 7: @c7a63270 length 8000002a status 0000002a Jan 4 14:56:08 heyzeus kernel: 8: @c7a63280 length 8000002a status 0000002a Jan 4 14:56:08 heyzeus kernel: 9: @c7a63290 length 8000002a status 0000002a Jan 4 14:56:08 heyzeus kernel: 10: @c7a632a0 length 8000002a status 0000002a Jan 4 14:56:08 heyzeus kernel: 11: @c7a632b0 length 8000002a status 0000002a Jan 4 14:56:08 heyzeus kernel: 12: @c7a632c0 length 8000002a status 0000002a Jan 4 14:56:08 heyzeus kernel: 13: @c7a632d0 length 8000002a status 0000002a Jan 4 14:56:08 heyzeus kernel: 14: @c7a632e0 length 8000002a status 8000002a Jan 4 14:56:08 heyzeus kernel: 15: @c7a632f0 length 8000002a status 8000002a Jan 4 14:56:08 heyzeus kernel: eth0: Resetting the Tx ring pointer. i can always ping the my ip address but i can't reach any farther then that. this happens with the patch for 2.2.17 (from http://www2.neweb.ne.jp/wd/fbm/3c556/) and with standard 2.2.18. any and all help would be appreciated. thanks, adam. below is some other (hopefully helpful) info: heyzeus(larry)$ lspci 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03) 00:02.0 CardBus bridge: Texas Instruments PCI1221 (rev 03) 00:02.1 CardBus bridge: Texas Instruments PCI1221 (rev 03) 00:03.0 Ethernet controller: 3Com Corporation: Unknown device 6056 (rev 20) 00:03.1 Communication controller: 3Com Corporation: Unknown device 1007 (rev 20) 00:05.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion Audio Accelerator] (rev 01) 00:07.0 Bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) 00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) 00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 03) 01:00.0 VGA compatible controller: S3 Inc.: Unknown device 8c12 (rev 11) heyzeus(larry)$ cat /proc/interrupts CPU0 0: 36958 XT-PIC timer 1: 2797 XT-PIC keyboard 2: 0 XT-PIC cascade 8: 1 XT-PIC rtc 11: 662 XT-PIC eth0 12: 4397 XT-PIC PS/2 Mouse 13: 1 XT-PIC fpu 14: 104456 XT-PIC ide0 15: 7 XT-PIC ide1 heyzeus(larry)$ cat /proc/ioports 0000-001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 02f8-02ff : serial(auto) 0376-0376 : ide1 03c0-03df : vga+ 03f6-03f6 : ide0 03f8-03ff : serial(auto) 1800-187f : eth0 1c00-1c07 : ide0 1c08-1c0f : ide1 From becker@scyld.com Fri, 5 Jan 2001 00:51:47 -0500 (EST) Date: Fri, 5 Jan 2001 00:51:47 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [vortex] irq troubles On Fri, 8 Dec 2000, cyber csycho wrote: > i dont mean to be blunt. my name is cyber csycho and i recently installed > the vortex drivers. they work but upon being invoked by modprobe they seem > to immediately acquire irq 0. how do i change it to acquire a different > irq #. please respond a.s.a.p. Thnak you!!!!!!!!!!!!! BIOS setup problem.. read http://www.scyld.com/expert/irq-conflict.html 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 From bogdan.costescu@iwr.uni-heidelberg.de Fri, 5 Jan 2001 08:55:42 +0100 (CET) Date: Fri, 5 Jan 2001 08:55:42 +0100 (CET) From: Bogdan Costescu bogdan.costescu@iwr.uni-heidelberg.de Subject: [vortex] 3c905CX things On Mon, 1 Jan 2001, Donald Becker wrote: > 32 milliseconds likely means that some hardware designer just put in a bogus > delay rather than do it correctly, just as some software people put in > patch-up code rather than fixing a bug source. OK, but the first reports said that even the 3Com driver doesn't work and it waits up to 1 second. A 32 ms delay should have been cought... Also, one of the first reports said that 2000000 PCI cycles were not enough, but 4000000 were - and the last one says that 50000 are enough. Maybe the measurements were affected by some other (?) conditions or maybe there are several different batches (which would be really nasty)... > It was to support cards with multiple transceivers, or an external MII > connector. To my knowledge, 3Com hasn't produced any such card. An HomePNA > card would be a likely product to use a second transceiver, but 3Com is just > putting their name on Broadcom hardware. But, as you said in a previous message, there is no code for MII transceiver selection. So, multiple transceivers will be detected, but only the first one will be used. Are there other drivers where transceiver selection is implemented (hopefully correctly) ? Sincerely, Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From bogdan.costescu@iwr.uni-heidelberg.de Fri, 5 Jan 2001 09:02:46 +0100 (CET) Date: Fri, 5 Jan 2001 09:02:46 +0100 (CET) From: Bogdan Costescu bogdan.costescu@iwr.uni-heidelberg.de Subject: [vortex] 3c905CX things On Mon, 1 Jan 2001, Andrew Morton wrote: > ... however he wouldn't have exercised the other > RxReset in vortex_error(). Why should this be different ? > It _is_ safe to schedule() within vortex_up(). It's not safe > to schedule() in vortex_probe() because of the probe/open race. > So long-term, a schedule_timeout(1) is a better approach to handling > the RxReset timer. So you want a timer to take care of this case ? How about vortex_error which is called from ISR ? > The change to the MII scan order works fine. In fact, this is > what 3com recommend in the 905C document: look at index 24 first. Still, the code is checking 24, 1->23, 0, 25-31. I think that 24, 1->31, 0 is better. Code is in: http://www.scyld.com/pipermail/vortex/2000-December/000845.html and it should also make obsolete the mdio_read(ioaddr, 24, 1) just before the MII scanning. Sincerely, Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From andrewm@uow.edu.au Fri, 05 Jan 2001 19:32:28 +1100 Date: Fri, 05 Jan 2001 19:32:28 +1100 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] 3c905CX things Bogdan Costescu wrote: > > On Mon, 1 Jan 2001, Andrew Morton wrote: > > > ... however he wouldn't have exercised the other > > RxReset in vortex_error(). > > Why should this be different ? Well, the chip is in a different state. It could be that the RxReset in this state is quick. Dunno. > > It _is_ safe to schedule() within vortex_up(). It's not safe > > to schedule() in vortex_probe() because of the probe/open race. > > So long-term, a schedule_timeout(1) is a better approach to handling > > the RxReset timer. > > So you want a timer to take care of this case ? Basically, yes. Busywaiting for tens of milliseconds is rude. > How about vortex_error which is called from ISR ? We'd have to busywait, or turn the driver inside out. > > > The change to the MII scan order works fine. In fact, this is > > what 3com recommend in the 905C document: look at index 24 first. > > Still, the code is checking 24, 1->23, 0, 25-31. I think that 24, 1->31, 0 > is better. Code is in: > > http://www.scyld.com/pipermail/vortex/2000-December/000845.html 3com say to check 24, then 0->31, skipping 24. So: /* * For the 3c905CX we look at index 24 first, because it bogusly * reports an external PHY at all indices */ if (phy == 0) phyx = 24; else if (phy <= 24) phyx = phy - 1; else phyx = phy; > and it should also make obsolete the mdio_read(ioaddr, 24, 1) just before > the MII scanning. Why was that ever needed? From bogdan.costescu@iwr.uni-heidelberg.de Fri, 5 Jan 2001 09:42:38 +0100 (CET) Date: Fri, 5 Jan 2001 09:42:38 +0100 (CET) From: Bogdan Costescu bogdan.costescu@iwr.uni-heidelberg.de Subject: [vortex] 3c905CX things On Fri, 5 Jan 2001, Andrew Morton wrote: > Well, the chip is in a different state. It could be that > the RxReset in this state is quick. Dunno. Or slower 8-( Anyway, failure to finish the RxReset completely in vortex_error would show up quickly, as the NIC will not receive packets anymore... > Basically, yes. Busywaiting for tens of milliseconds is rude. But the init sequence should be done in order. vortex_open() will not finish faster. AFAIK, ifconfig waits for vortex_open() to return, so there is no advantage in the start-up sequence (like init-ing more interfaces at the same time). The only difference is that is frees the CPU and the bus; for a normal power-on sequence, this should not make much difference, however, for insmod/rmmod later, it will. > > How about vortex_error which is called from ISR ? > We'd have to busywait, or turn the driver inside out. Yep. > if (phy == 0) > phyx = 24; > else if (phy <= 24) > phyx = phy - 1; > else > phyx = phy; This is 24, 0->23, 25->31. Don has said in a previous thread that 0 should be checked last, that's why I proposed it that way. Because we only need to detect one transceiver, if the transceiver at 24 was not detected at the first iteration, it should not appear at the 25th, so I thought that it's safe to have 24, 1->31, 0. > Why was that ever needed? It seems that some older generation cards need to have this read in order for the MII detection routine to work; otherwise, bogus results appear (like now with CXs). Sincerely, Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From andrewm@uow.edu.au Sat, 06 Jan 2001 01:13:39 +1100 Date: Sat, 06 Jan 2001 01:13:39 +1100 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] problems with 2.2.18 / 3c556B driver Adam Shand wrote: > > hi. > > i have this problem on a thinkpad t20. the card works great until i > suspend/resume. the only way i can find to fix it is to reboot (unloading > and reloading the module does not work). a friend i work with also has a > t20 and reloading the module works just fine for him (with the same > kernel). both of us are running stock debian (woody) boxes. > > Right at the end of the driver could you please try the following? while (root_vortex_dev) { struct vortex_private *vp=(void *)(root_vortex_dev->priv); next_dev = vp->next_module; unregister_netdev(root_vortex_dev); - outw(TotalReset, root_vortex_dev->base_addr + EL3_CMD); + outw(TotalReset | 0x10, root_vortex_dev->base_addr + EL3_CMD); release_region(root_vortex_dev->base_addr, pci_tbl[vp->chip_id].io_size); kfree(root_vortex_dev); kfree(vp->priv_addr); root_vortex_dev = next_dev; } and let us know? Thanks. From larry@spack.org Fri, 5 Jan 2001 15:45:48 -0800 (PST) Date: Fri, 5 Jan 2001 15:45:48 -0800 (PST) From: Adam Shand larry@spack.org Subject: [vortex] problems with 2.2.18 / 3c556B driver this solved the problem. it still doesn't work after a suspend/resume cycle but after reloading the module it works just fine. thanks! if there's anything else i can to do help please just let me know. adam. > Right at the end of the driver could you please try the following? > > while (root_vortex_dev) { > struct vortex_private *vp=(void *)(root_vortex_dev->priv); > next_dev = vp->next_module; > unregister_netdev(root_vortex_dev); > - outw(TotalReset, root_vortex_dev->base_addr + EL3_CMD); > + outw(TotalReset | 0x10, root_vortex_dev->base_addr + EL3_CMD); > release_region(root_vortex_dev->base_addr, > pci_tbl[vp->chip_id].io_size); > kfree(root_vortex_dev); > kfree(vp->priv_addr); > root_vortex_dev = next_dev; > } > > and let us know? > > Thanks. > From andrewm@uow.edu.au Sun, 07 Jan 2001 18:35:17 +1100 Date: Sun, 07 Jan 2001 18:35:17 +1100 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] 3c590 media selection Hi, Don. I've been looking into a 590 problem report where if the 10baseT cable is pulled out the NIC goes inoperative. What happens is that the selection logic rotates to 10base2 and then gets stuck there because 10base2 has no link beat indication. The comment in the code says "Other media types handled by Tx timeouts." There is no implementation of this, so I put it in. It doesn't work very well, because we seem to be able to send packets into thin air across 10base2. I would _occasionally_ get a tx timeout, and the driver would then advance to AUI and get completely stuck, because we can happily transmit packets into thin air across AUI as well. I don't really see a sensible algorithmic fix for this, so I took the tx timeout logic out again. So we're left with forcing the media type via module parameters. But there's a problem with the vortex_timer logic. Even if we try to force 10baseT via `options=0', this code: media_status = inw(ioaddr + Wn4_Media); switch (dev->if_port) { case XCVR_10baseT: case XCVR_100baseTx: case XCVR_100baseFx: if (media_status & Media_LnkBeat) { ok = 1; if (vortex_debug > 1) printk(KERN_DEBUG "%s: Media %s has link beat, %x.\n", dev->name, media_tbl[dev->if_port].name, media_status); } else if (vortex_debug > 1) printk(KERN_DEBUG "%s: Media %s is has no link beat, %x.\n", dev->name, media_tbl[dev->if_port].name, media_status); break; will always cause the driver to advance onto the next media type, which causes it to get stuck on 10base2. So what I did was to add a new flag to the device structure `media_was_forced'. Set it in the processing of module options: if (option >= 0) { vp->media_override = ((option & 7) == 2) ? 0 : option & 15; if (vp->media_override != 7) vp->media_was_forced = 1; And test it vortex_timer: if (vp->media_was_forced) goto leave_media_alone; disable_irq(dev->irq); enable_irq(dev->irq); leave_media_alone: if (vortex_debug > 2) printk(KERN_DEBUG "%s: Media selection timer finished, %s.\n", dev->name, media_tbl[dev->if_port].name); vp->timer.expires = RUN_AT(next_tick); add_timer(&vp->timer); if (vp->deferred) outw(FakeIntr, ioaddr + EL3_CMD); return; } Does all this make sense? Thanks. From becker@scyld.com Sun, 7 Jan 2001 03:23:49 -0500 (EST) Date: Sun, 7 Jan 2001 03:23:49 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [vortex] 3c590 media selection On Sun, 7 Jan 2001, Andrew Morton wrote: > I've been looking into a 590 problem report where if the > 10baseT cable is pulled out the NIC goes inoperative. > > What happens is that the selection logic rotates to > 10base2 and then gets stuck there because 10base2 > has no link beat indication. Yes, that's a problem. It's a hardware limitation. IIRC, we must select the 10baseT transceiver for some significant time to reliably detect 10baseT link beat, so we risk dropping a 10base2 packet if we poll. > The comment in the code says "Other media types handled > by Tx timeouts." We can detect a 10base2 cable by Receiving a packet with a good CRC. Transmitting a packet without a 16 collision error. The problem with this is that we might have a quiet 10base2 network, and having the driver construct a test packet is evil. So we assume that the protocol code will eventually send a packet, perhaps a keep-alive or retransmit, and that we can detect a disconnected cable that way. > It doesn't work very well, because we seem to be able to > send packets into thin air across 10base2. I would _occasionally_ > get a tx timeout, and the driver would then advance to > AUI and get completely stuck, because we can happily transmit > packets into thin air across AUI as well. Yup, 10base2 is bad but AUI is worse. You can't use heartbeat. > I don't really see a sensible algorithmic fix for this, > so I took the tx timeout logic out again. > > So we're left with forcing the media type via > module parameters. That was my conclusion. The alternative is logic that combines If we have ever seen 10baseT link beat, poll 10baseT when we have no Rx traffic for T seconds. If we have ever received 10base2 packets, don't switch to AUI. But this doesn't seem worthwhile, given that the 3c590 is ancient. > But there's a problem with the vortex_timer logic. Even > if we try to force 10baseT via `options=0', this code: > > media_status = inw(ioaddr + Wn4_Media); > switch (dev->if_port) { > case XCVR_10baseT: case XCVR_100baseTx: case XCVR_100baseFx: > if (media_status & Media_LnkBeat) { > ok = 1; > if (vortex_debug > 1) > printk(KERN_DEBUG "%s: Media %s has link beat, %x.\n", > dev->name, media_tbl[dev->if_port].name, media_status); > } else if (vortex_debug > 1) > printk(KERN_DEBUG "%s: Media %s is has no link beat, %x.\n", > dev->name, media_tbl[dev->if_port].name, media_status); > break; > > will always cause the driver to advance onto the next media type, > which causes it to get stuck on 10base2. It shouldn't -- see the ok=1 path. > So what I did was to add a new flag to the device structure > `media_was_forced'. Set it in the processing of module I use the name medialock in my drivers. I frequently also need duplex_lock 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 From andrewm@uow.edu.au Sun, 07 Jan 2001 19:53:59 +1100 Date: Sun, 07 Jan 2001 19:53:59 +1100 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] 3c590 media selection Donald Becker wrote: > > On Sun, 7 Jan 2001, Andrew Morton wrote: > > > I've been looking into a 590 problem report where if the > > 10baseT cable is pulled out the NIC goes inoperative. > > > > What happens is that the selection logic rotates to > > 10base2 and then gets stuck there because 10base2 > > has no link beat indication. > > Yes, that's a problem. It's a hardware limitation. > > IIRC, we must select the 10baseT transceiver for some significant time to > reliably detect 10baseT link beat, so we risk dropping a 10base2 packet if > we poll. 1.4 seconds. > ... > > Yup, 10base2 is bad but AUI is worse. You can't use heartbeat. > > ... > > > I don't really see a sensible algorithmic fix for this, > > so I took the tx timeout logic out again. > > > > So we're left with forcing the media type via > > module parameters. > > That was my conclusion. > > The alternative is logic that combines > If we have ever seen 10baseT link beat, poll 10baseT when we have no Rx > traffic for T seconds. > If we have ever received 10base2 packets, don't switch to AUI. > > But this doesn't seem worthwhile, given that the 3c590 is ancient. Fair enough. > > But there's a problem with the vortex_timer logic. Even > > if we try to force 10baseT via `options=0', this code: > > > > media_status = inw(ioaddr + Wn4_Media); > > switch (dev->if_port) { > > case XCVR_10baseT: case XCVR_100baseTx: case XCVR_100baseFx: > > if (media_status & Media_LnkBeat) { > > ok = 1; > > if (vortex_debug > 1) > > printk(KERN_DEBUG "%s: Media %s has link beat, %x.\n", > > dev->name, media_tbl[dev->if_port].name, media_status); > > } else if (vortex_debug > 1) > > printk(KERN_DEBUG "%s: Media %s is has no link beat, %x.\n", > > dev->name, media_tbl[dev->if_port].name, media_status); > > break; > > > > will always cause the driver to advance onto the next media type, > > which causes it to get stuck on 10base2. > > It shouldn't -- see the ok=1 path. In this case, dev->if_port is XCVR_10baseT, from `options'. But there's no link beat, so `ok' remains at zero and we go on to select the next media type. I tested 0.99Ra with the 3c590, BTW. It too got stuck on the 10base2 port when the 10baseT cable was removed. > > So what I did was to add a new flag to the device structure > > `media_was_forced'. Set it in the processing of module > > I use the name medialock in my drivers. I'll do that. Thanks. From becker@scyld.com Sun, 7 Jan 2001 03:59:47 -0500 (EST) Date: Sun, 7 Jan 2001 03:59:47 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [vortex] 3c590 media selection On Sun, 7 Jan 2001, Andrew Morton wrote: > > IIRC, we must select the 10baseT transceiver for some significant time to > > reliably detect 10baseT link beat, so we risk dropping a 10base2 packet if > > we poll. > 1.4 seconds. Unrelated note: Autonegotation takes up to 3.0 seconds. It used to be documented as 2.4, but they missed an unlikely even-worse-case scenerio. > In this case, dev->if_port is XCVR_10baseT, from `options'. But there's > no link beat, so `ok' remains at zero and we go on to select the next > media type. > > I tested 0.99Ra with the 3c590, BTW. It too got stuck on the 10base2 > port when the 10baseT cable was removed. > > > What happens is that the selection logic rotates to > > > 10base2 and then gets stuck there because 10base2 > > > has no link beat indication. Hmmm, after thinking about this for a while, it might make sense to have the following semantics for the 3c590: if 10baseT link beat is ever detected, lock the media down to 10baseT. It's pretty unlikely that a user would disconnect 10baseT and expect the card to switch to 10base2. The only case I can think of is using a 10base2 network as a fail-over when the 10baseT hub loses power. It's much more likely that losing 10baseT link beat is temporary, and the user doesn't expect the card to work until link beat returns. 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 From andrewm@uow.edu.au Sun, 07 Jan 2001 21:39:44 +1100 Date: Sun, 07 Jan 2001 21:39:44 +1100 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] 3c590 media selection Donald Becker wrote: > > On Sun, 7 Jan 2001, Andrew Morton wrote: > > > > IIRC, we must select the 10baseT transceiver for some significant time to > > > reliably detect 10baseT link beat, so we risk dropping a 10base2 packet if > > > we poll. > > 1.4 seconds. > > Unrelated note: Autonegotation takes up to 3.0 seconds. It used to be > documented as 2.4, but they missed an unlikely even-worse-case scenerio. The driver has 3.0. That's a very long time. Why should it take more than a microsecond? > > In this case, dev->if_port is XCVR_10baseT, from `options'. But there's > > no link beat, so `ok' remains at zero and we go on to select the next > > media type. > > > > I tested 0.99Ra with the 3c590, BTW. It too got stuck on the 10base2 > > port when the 10baseT cable was removed. > > > > > What happens is that the selection logic rotates to > > > > 10base2 and then gets stuck there because 10base2 > > > > has no link beat indication. > > Hmmm, after thinking about this for a while, it might make sense to have the > following semantics for the 3c590: > if 10baseT link beat is ever detected, lock the media down to 10baseT. > > It's pretty unlikely that a user would disconnect 10baseT and expect the > card to switch to 10base2. The only case I can think of is using a 10base2 > network as a fail-over when the 10baseT hub loses power. > > It's much more likely that losing 10baseT link beat is temporary, and the > user doesn't expect the card to work until link beat returns. Yes, it is tricky. I think the problem with this scheme is the situation where the machine is booted with no ethernet attached. It flips over to 10base2 and stays there, which is probably irritating. With the `medialock' change, users can reliably select their interface via configuration. The problem which remains is that people won't know that they basically *have* to provide an `options' argument to keep the 3c590 sane. They'll just load the driver with no options and get used to reloading the driver or rebooting every time they disconnect the cable. So perhaps it would be best to always lock down the media type for a 3c590. If no `options' were provided we lock it down to the `default' value from EEPROM. All we really lose from this is the ability to failover to 10base2, and as you say this is probably a rare requirement. And given that there's no way to get back to the 10baseT inerface apart from reloading the driver, it's perhaps not a very useful feature. From becker@scyld.com Sun, 7 Jan 2001 13:40:17 -0500 (EST) Date: Sun, 7 Jan 2001 13:40:17 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [vortex] 3c590 media selection On Sun, 7 Jan 2001, Andrew Morton wrote: > > Unrelated note: Autonegotation takes up to 3.0 seconds. It used to be > > documented as 2.4, but they missed an unlikely even-worse-case scenerio. > > The driver has 3.0. > > That's a very long time. Why should it take more than a microsecond? Quick tutorial: Autonegotiation takes place on top of the 10baseT link beat. 10baseT link beat was originally a few bits transmitted every 16.8 milliseconds when the link is idles. The link beat looks like an incomplete packet preamble, and is ignored by the Ethernet hardware. Link beat was a clever way to verify that the link was established -- the Rx data LED indicated that the link was connected. Autonegotiation encodes one communication word in the same 16.8 msec period. The data looks like link beat pulses to old hardware, but the pulses are carefully timed to communicate an 11-13 bit word. The same word is retransmitted until acknowledged. For reliability the receiver must see the same data at least three times before acknowledging. Add on the time to switch to the negotiated mode at it starts taking a human-perceivable amount of time to complete autonegotiation. See http://scyld.com/expert/NWay.html for more information on how this works. > > > In this case, dev->if_port is XCVR_10baseT, from `options'. But there's > > > no link beat, so `ok' remains at zero and we go on to select the next > > > media type. ... > I think the problem with this scheme is the situation where the machine > is booted with no ethernet attached. It flips over to 10base2 and stays > there, which is probably irritating. Our goal is to have almost properly connected systems working with no options. I think that we can consider the system above as "not properly connected". > to keep the 3c590 sane. They'll just load the driver with no > options and get used to reloading the driver or rebooting every > time they disconnect the cable. The disconnect-the-cable scenerio is the only one that concerns me. The driver should continue to work even with a temporary loss of link beat. That situation won't be solved by an override, because the driver will work with the default when they initially install and the user won't know they need to force the media type to have a reliable connection. > So perhaps it would be best to always lock down the media type for > a 3c590. If no `options' were provided we lock it down to the > `default' value from EEPROM. IIRC, the default value is '0' which means autoselect preferring 10baseT. BTW, there are two concepts for forced-10baseT Media lock to 10baseT, but require link beat before transmitting Ignore link beat 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 From Pekka.Pessi@nokia.com 10 Jan 2001 12:25:41 +0200 Date: 10 Jan 2001 12:25:41 +0200 From: Pekka Pessi Pekka.Pessi@nokia.com Subject: [vortex] 3C556B and 2.4.0 Hi, Adam Shand wrote: >Right at the end of the driver could you please try the following? > >- outw(TotalReset, root_vortex_dev->base_addr + EL3_CMD); >+ outw(TotalReset | 0x10, root_vortex_dev->base_addr + EL3_CMD); I noticed that the following cures the problems with 3C556B on 2.4.0 kernel. I have no idea if it breaks everything else, however. Pekka --- 3c59x.c-virgin Tue Jan 9 16:12:47 2001 +++ 3c59x.c Tue Jan 9 16:13:18 2001 @@ -2572,7 +2572,7 @@ * here */ unregister_netdev(dev); - outw(TotalReset, dev->base_addr + EL3_CMD); + outw(TotalReset | 0x10, dev->base_addr + EL3_CMD); if (vp->must_free_region) release_region(dev->base_addr, vp->io_size); kfree(dev); @@ -2623,7 +2623,7 @@ ioaddr = dev->base_addr; unregister_netdev (dev); - outw (TotalReset, ioaddr + EL3_CMD); + outw (TotalReset | 0x10, ioaddr + EL3_CMD); release_region (ioaddr, VORTEX_TOTAL_SIZE); tmp = dev; From Herbert.Huber@lrz-muenchen.de Thu, 11 Jan 2001 11:30:50 +0100 Date: Thu, 11 Jan 2001 11:30:50 +0100 From: Herbert Huber Herbert.Huber@lrz-muenchen.de Subject: [vortex] Problems getting vortex driver working for 3c905C NIC Hello, we have serious problems, getting our 3c905C NIC's which come with the newest DELL P4 Dimesion systems working under linux-2.4.0, using the vortex driver. Loading the 3c59x.o module logs the following information in our syslog file: Jan 10 19:02:44 lxsrv13 kernel: 3c59x.c:LK1.1.11 13 Nov 2000 Donald Becker and others. http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $ Jan 10 19:02:44 lxsrv13 kernel: See Documentation/networking/vortex.txt Jan 10 19:02:44 lxsrv13 kernel: eth0: 3Com PCI 3c905C Tornado at 0xec00, 00:b0:d0:14:76:4b, IRQ 3 Jan 10 19:02:44 lxsrv13 kernel: 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. Jan 10 19:02:44 lxsrv13 kernel: Media override to transceiver type 0 (10baseT). Jan 10 19:02:44 lxsrv13 kernel: Enabling bus-master transmits and whole-frame receives. Jan 10 19:02:58 lxsrv13 kernel: eth0: command 0x2800 did not complete! Status=0x7000 For the 2.2 kernel series we could succesfully operate these NIC's, using the 3c90x.c driver sources from the SuSE 7.0 distribution. Unfortunatelly this driver is not 2.4.0-ready, so that we cannot upgrade to 2.4.0 at the moment. Is there a chance to get the vortex driver working with our onboard NIC's (DELL unfortunatelly doesn't further spezify the version of the 3com chip used). If yes, please tell me if further information is needed. Regards /Herbert From andrewm@uow.edu.au Fri, 12 Jan 2001 00:18:38 +1100 Date: Fri, 12 Jan 2001 00:18:38 +1100 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] Problems getting vortex driver working for 3c905C NIC Herbert Huber wrote: > > Hello, > > we have serious problems, getting our 3c905C NIC's which come with the > newest DELL P4 Dimesion systems working under linux-2.4.0, using the > vortex driver. Loading the 3c59x.o module logs the following > information in our syslog file: Replace the driver with http://www.uow.edu.au/~andrewm/linux/3c59x.c-2.4.0-1.gz Or grab the 2.4.1-pre1 kernel from the kernel mirrors. From bogdan.costescu@iwr.uni-heidelberg.de Thu, 11 Jan 2001 14:12:23 +0100 (CET) Date: Thu, 11 Jan 2001 14:12:23 +0100 (CET) From: Bogdan Costescu bogdan.costescu@iwr.uni-heidelberg.de Subject: [vortex] Problems getting vortex driver working for 3c905C NIC On Thu, 11 Jan 2001, Herbert Huber wrote: > we have serious problems, getting our 3c905C NIC's which come with the > newest DELL P4 Dimesion systems working under linux-2.4.0, using the > vortex driver... > Jan 10 19:02:58 lxsrv13 kernel: eth0: command 0x2800 did not complete! > Status=0x7000 I guess that this is another 905CX card. The driver in 2.4.0 is not "ready" for it; the patch from Andrew to correct this should be in 2.4.1-pre1. (ftp://ftp.de.kernel.org/pub/linux/kernel/testing/) > For the 2.2 kernel series we could succesfully operate these NIC's, > using the 3c90x.c driver... The initial CX cards didn't operate properly even with 3c90x driver; it seems that 3Com has at least 2 generations of these cards... > Jan 10 19:02:44 lxsrv13 kernel: 8K byte-wide RAM 5:3 Rx:Tx split, > autoselect/Autonegotiate interface. > Jan 10 19:02:44 lxsrv13 kernel: Media override to transceiver type 0 > (10baseT). This indicates that you don't force any media type, but the driver honours the EEPROM setting which is 10baseT. If you don't want to do this, you can either pass an option to the module to force some media type or use the DOS config tool from 3Com to change it back to autonegotiation. Sincerely, Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From andrewm@uow.edu.au Sat, 13 Jan 2001 00:38:19 +1100 Date: Sat, 13 Jan 2001 00:38:19 +1100 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] 3C556B and 2.4.0 Pekka Pessi wrote: > > Hi, > > Adam Shand wrote: > >Right at the end of the driver could you please try the following? > > > >- outw(TotalReset, root_vortex_dev->base_addr + EL3_CMD); > >+ outw(TotalReset | 0x10, root_vortex_dev->base_addr + EL3_CMD); > > I noticed that the following cures the problems with 3C556B on 2.4.0 > kernel. I have no idea if it breaks everything else, however. > Good point. Thanks. With some reluctance but more expediency I'll slot this into the drivers, but only for the 556B. With this change, is it still necessary to reload the driver after a PM resume? From Shawn.Starr@Home.net Fri, 12 Jan 2001 16:37:35 -0500 Date: Fri, 12 Jan 2001 16:37:35 -0500 From: Shawn Starr Shawn.Starr@Home.net Subject: [vortex] [PROBLEM]: Strange network problems with 2.4.0 and 3c59x.o Here's something strange that i've been noticing with 2.4.0. Some websites I am unable to access now. For example: http://www.scotiabank.ca/simplify/index.html if your in Canada and you have Scotia banking online, try and access their banking sites. It will just hang. However upon trying the same in Windows 2000 (cough). The site works fine. Could there be a network driver issue as even trying with telnet port 80 fails as well? Im not sure on this one this seems bizarre. I have the same problem with www.workopolis.com, theglobeandmail.com, perhaps there's some sort of packet or frame not being processed properly? I can ICMP ping all the sites fine and i can access them from other shells. I have spoken to some of their engineers and they say that there is nothing blocking/no firewalls configured to deny access to theses sites. If there's any information you need I'd be glad to try and figure this one out. Shawn S. From matti.aarnio@zmailer.org Fri, 12 Jan 2001 23:58:07 +0200 Date: Fri, 12 Jan 2001 23:58:07 +0200 From: Matti Aarnio matti.aarnio@zmailer.org Subject: [vortex] Re: [PROBLEM]: Strange network problems with 2.4.0 and 3c59x.o On Fri, Jan 12, 2001 at 04:37:35PM -0500, Shawn Starr wrote: > Here's something strange that i've been noticing with 2.4.0. Some > websites I am unable to access now. For example: This is FAQish thing. DON'T USE TCP_ECN unless you want trouble! # echo 0 > /proc/sys/net/ipv4/tcp_ecn > Shawn S. /Matti Aarnio From becker@scyld.com Fri, 12 Jan 2001 17:02:05 -0500 (EST) Date: Fri, 12 Jan 2001 17:02:05 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [vortex] Re: [PROBLEM]: Strange network problems with 2.4.0 and 3c59x.o On Fri, 12 Jan 2001, Shawn Starr wrote: > Here's something strange that i've been noticing with 2.4.0. Some websites I am > unable to access now. For example: > > http://www.scotiabank.ca/simplify/index.html This is a bug in the routers (likely Cisco) on the path there. It's related to ECN (Early Congestion Notification), which the router does not handle correctly. Routers that do not understand the option should ignore it. Instead they discard the packet. See the earlier discussion about "ECN" on the linux-kernel list. > Could there be a network driver issue as even trying with telnet port > 80 fails as well? It's not a driver issue. > Im not sure on this one this seems bizarre. I have the same problem with > www.workopolis.com, theglobeandmail.com, perhaps there's some sort of > packet or frame not being processed properly? > > I can ICMP ping all the sites fine and i can access them from other shells. > I have spoken to some of their engineers and they say that there is nothing > blocking/no firewalls configured to deny access to theses sites. Ask them about when they last updated their routers... 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 From andrewm@uow.edu.au Sat, 13 Jan 2001 12:55:17 +1100 Date: Sat, 13 Jan 2001 12:55:17 +1100 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] 3c590 media selection Donald Becker wrote: > > > to keep the 3c590 sane. They'll just load the driver with no > > options and get used to reloading the driver or rebooting every > > time they disconnect the cable. > > The disconnect-the-cable scenerio is the only one that concerns me. The > driver should continue to work even with a temporary loss of link beat. > That situation won't be solved by an override, because the driver will work > with the default when they initially install and the user won't know they > need to force the media type to have a reliable connection. > Thanks, Donald. I'll be leaving it the way you suggest - if no media-selection options are provided, we still do software autoselection. If options _are_ provided, we set medialock and the NIC is locked onto the media which was selected. Another question: in vortex_timer(), for the MII/NWAY case we don't check to see whether autonegotiation has completed. Should we? From mharris@opensourceadvocate.org Sat, 13 Jan 2001 20:03:25 -0500 (EST) Date: Sat, 13 Jan 2001 20:03:25 -0500 (EST) From: Mike A. Harris mharris@opensourceadvocate.org Subject: [vortex] Re: [PROBLEM]: Strange network problems with 2.4.0 and 3c59x.o On Fri, 12 Jan 2001, Shawn Starr wrote: Snoop through /proc, and you'll find a file where you can disable "ecn" support. echo 0 > /proc.... >Date: Fri, 12 Jan 2001 16:37:35 -0500 >From: Shawn Starr >To: Donald Becker , vortex@scyld.com, > linux-kernel@vger.kernel.org >Content-Type: text/plain; charset=iso-8859-15 >Subject: [PROBLEM]: Strange network problems with 2.4.0 and 3c59x.o > >Here's something strange that i've been noticing with 2.4.0. Some websites I am >unable to access now. For example: > >http://www.scotiabank.ca/simplify/index.html > >if your in Canada and you have Scotia banking online, try and access their >banking sites. It will just hang. However upon trying the same in Windows 2000 >(cough). The site works fine. > >Could there be a network driver issue as even trying with telnet port 80 fails >as well? > >Im not sure on this one this seems bizarre. I have the same problem with >www.workopolis.com, theglobeandmail.com, perhaps there's some sort of packet or >frame not being processed properly? > >I can ICMP ping all the sites fine and i can access them from other shells. >I have spoken to some of their engineers and they say that there is nothing >blocking/no firewalls configured to deny access to theses sites. > >If there's any information you need I'd be glad to try and figure this one out. > >Shawn S. > > > >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to majordomo@vger.kernel.org >Please read the FAQ at http://www.tux.org/lkml/ > ---------------------------------------------------------------------- Mike A. Harris - Linux advocate - Free Software advocate This message is copyright 2001, all rights reserved. Views expressed are my own, not necessarily shared by my employer. ---------------------------------------------------------------------- VMS is a text-only adventure game. If you win you can use unix. From fsb@healy.washington.dc.us Sun, 14 Jan 2001 23:25:00 -0500 Date: Sun, 14 Jan 2001 23:25:00 -0500 From: Liam M. Healy fsb@healy.washington.dc.us Subject: [vortex] 3C905CX-TXM Recently I purchased a Dell Dimension L700cx and attempted to install Debian 2.2r2 with Linux kernel 2.2.18pre21. This computer has a 3Com NIC which has "3C905CX-TXM" silkscreened above the barcode. Despite the name, the existing 3c59x drivers, which are supposed to work with the 3c905 series, do not work with this card as-is. I found the solution posted to this mailing list http://www.scyld.com/pipermail/vortex/2000-December/000858.html Specifically, from ftp://ftp.scyld.com/pub/network/3c59x.c "3c59x.c:v0.99Qk 7/5/2000 Donald Becker, becker@scyld.com" make the following changes: 893d892 < /* LMH changed per http://www.scyld.com/pipermail/vortex/2000-December/000858.html */ 895c894 < mdio_sync(ioaddr, 32); --- > mii_preamble_required++; 897,904c896,897 < for (phy = 0; phy < 32 && phy_idx < 1; phy++) { < int mii_status, phyx = (phy == 0 ? 24 : phy == 24 ? 0 : phy); < /* mii_preamble_required++; < mii_preamble_required++; < mdio_read(ioaddr, 24, 1); < for (phy = 1; phy <= 32 && phy_idx < sizeof(vp->phys); phy++) { < int mii_status, phyx = phy & 0x1f; < */ --- > for (phy = 1; phy <= 32 && phy_idx < sizeof(vp->phys); phy++) { > int mii_status, phyx = phy & 0x1f; 1168,1170c1161 < /* LMH changed per http://www.scyld.com/pipermail/vortex/2000-December/000858.html */ < for (i = 50000; i >= 0 ; i--) < /* for (i = 2000; i >= 0 ; i--) */ --- > for (i = 2000; i >= 0 ; i--) This will make the card function. Liam Healy From Pekka.Pessi@nokia.com 15 Jan 2001 14:25:47 +0200 Date: 15 Jan 2001 14:25:47 +0200 From: Pekka Pessi Pekka.Pessi@nokia.com Subject: [vortex] 3C556B and 2.4.0 In message <3A5F08CB.FA73BE89@uow.edu.au> "Andrew Morton" writes: >> I noticed that the following cures the problems with 3C556B on 2.4.0 >> kernel. I have no idea if it breaks everything else, however. >With some reluctance but more expediency I'll slot this into >the drivers, but only for the 556B. >With this change, is it still necessary to reload the driver >after a PM resume? Yes. I have to rmmod 3c59x when suspending. Without this patch the driver was not able to get the correct MAC address (it got ff:ff:ff:ff:ff: ff), nor transmit or receive any packets. Pekka ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** . From illo@pypki.org Mon, 15 Jan 2001 23:16:16 +0100 Date: Mon, 15 Jan 2001 23:16:16 +0100 From: Illo de' Illis illo@pypki.org Subject: [vortex] 3c575_cb.c and the 3CXFEM656C CardBus PCMCIA Ok, I'm trying to get this card working on my system (an Acer Travelmate 332T with Linux 2.4.0-ac9). I've tried the 2.4.0 kernel with internal PCI->CardBus + 3c59x, and the 2.4.0 kernel without PCMCIA support and external 3.1.23 PCMCIA package drivers. The first configuration fails to load the driver claiming that it is unable to find the right IRQ of the card. I've tried setting the kernel option 'pci=biosirq' as suggested but it behaves the same. The second configuration fails because it cannot allocate 512 IO ports: -- Jan 15 22:31:04 knuth kernel: Linux PCMCIA Card Services 3.1.23 Jan 15 22:31:04 knuth kernel: kernel build: 2.4.0-ac9 #6 Mon Jan 15 20:35:20 CET 2001 Jan 15 22:31:04 knuth kernel: options: [pci] [cardbus] [apm] Jan 15 22:31:05 knuth kernel: Intel PCIC probe: PCI: Guessed IRQ 9 for device 00:13.0 Jan 15 22:31:05 knuth kernel: Jan 15 22:31:05 knuth kernel: O2Micro OZ6812 rev 05 PCI-to-CardBus at slot 00:13, mem 0x10000000 Jan 15 22:31:05 knuth kernel: host opts [0]: [ring] [pci+isa] [pci irq 9] [lat 32/176] [bus 2/5] Jan 15 22:31:05 knuth kernel: ISA irqs (default) = 3,4,7,12 PCI status changes Jan 15 22:31:05 knuth kernel: cs: IO port probe 0x0c00-0x0cff: clean. Jan 15 22:31:05 knuth kernel: cs: IO port probe 0x0800-0x08ff: clean. Jan 15 22:31:05 knuth kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x3c0-0x3df 0x3f8-0x3ff 0x408-0x40f 0x480-0x48f 0x4d0-0x4d7 Jan 15 22:31:05 knuth kernel: cs: IO port probe 0x0a00-0x0aff: clean. Jan 15 22:31:05 knuth kernel: cs: cb_alloc(bus 2): vendor 0x10b7, device 0x6564 Jan 15 22:31:05 knuth kernel: 3c59x.c:v0.99Q 5/16/2000 Donald Becker, becker@scyld.com Jan 15 22:31:05 knuth kernel: http://www.scyld.com/network/vortex.html Jan 15 22:31:05 knuth kernel: cs: cb_config(bus 2) Jan 15 22:31:05 knuth kernel: cs: could not allocate 512 IO ports for CardBus socket 0 Jan 15 22:31:05 knuth kernel: Trying to free nonexistent resource <00000000-000001ff> Jan 15 22:31:05 knuth kernel: 3c575_cb: RequestIO: Out of resource Jan 15 22:45:05 knuth kernel: cs: cb_free(bus 2) -- I searched (not quite deeply, actually) in this mailing list archive but found nothing about this problem... what's wrong with that? Ciao, Illo. -- ---------------------------------------------------------------------------- Ilario Nardinocchi, illo@CS.UniBO.IT - Computer Science Adept since 1982 illo@pypki.org - Oy gevalt, I'm so ferklempt that I could plotz! Know-nothing-bozo rule: The views expressed above are entirely mine and do not represent the views, policy or understanding of any other person or official body. ---------------------------------------------------------------------------- From andrewm@uow.edu.au Tue, 16 Jan 2001 11:39:30 +1100 Date: Tue, 16 Jan 2001 11:39:30 +1100 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] 3c575_cb.c and the 3CXFEM656C CardBus PCMCIA Not good. Could you please go back to the first combination (kernel Cardbus+3c59x) and send the `dmesg' output. Also, run `lspci -vvxx' and send the output which relates to the 3c656. David may be able to suggest why the cardservices layer can't allocate the I/O space? Illo de' Illis wrote: > > Ok, I'm trying to get this card working on my system (an Acer Travelmate 332T > with Linux 2.4.0-ac9). I've tried the 2.4.0 kernel with internal > PCI->CardBus + 3c59x, and the 2.4.0 kernel without PCMCIA support and > external 3.1.23 PCMCIA package drivers. > The first configuration fails to load the driver claiming that it is unable to > find the right IRQ of the card. I've tried setting the kernel option > 'pci=biosirq' as suggested but it behaves the same. > The second configuration fails because it cannot allocate 512 IO ports: > > -- > Jan 15 22:31:04 knuth kernel: Linux PCMCIA Card Services 3.1.23 > Jan 15 22:31:04 knuth kernel: kernel build: 2.4.0-ac9 #6 Mon Jan 15 20:35:20 CET 2001 > Jan 15 22:31:04 knuth kernel: options: [pci] [cardbus] [apm] > Jan 15 22:31:05 knuth kernel: Intel PCIC probe: PCI: Guessed IRQ 9 for device 00:13.0 > Jan 15 22:31:05 knuth kernel: > Jan 15 22:31:05 knuth kernel: O2Micro OZ6812 rev 05 PCI-to-CardBus at slot 00:13, mem 0x10000000 > Jan 15 22:31:05 knuth kernel: host opts [0]: [ring] [pci+isa] [pci irq 9] [lat 32/176] [bus 2/5] > Jan 15 22:31:05 knuth kernel: ISA irqs (default) = 3,4,7,12 PCI status changes > Jan 15 22:31:05 knuth kernel: cs: IO port probe 0x0c00-0x0cff: clean. > Jan 15 22:31:05 knuth kernel: cs: IO port probe 0x0800-0x08ff: clean. > Jan 15 22:31:05 knuth kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x3c0-0x3df 0x3f8-0x3ff 0x408-0x40f 0x480-0x48f 0x4d0-0x4d7 > Jan 15 22:31:05 knuth kernel: cs: IO port probe 0x0a00-0x0aff: clean. > Jan 15 22:31:05 knuth kernel: cs: cb_alloc(bus 2): vendor 0x10b7, device 0x6564 > Jan 15 22:31:05 knuth kernel: 3c59x.c:v0.99Q 5/16/2000 Donald Becker, becker@scyld.com > Jan 15 22:31:05 knuth kernel: http://www.scyld.com/network/vortex.html > Jan 15 22:31:05 knuth kernel: cs: cb_config(bus 2) > Jan 15 22:31:05 knuth kernel: cs: could not allocate 512 IO ports for CardBus socket 0 > Jan 15 22:31:05 knuth kernel: Trying to free nonexistent resource <00000000-000001ff> > Jan 15 22:31:05 knuth kernel: 3c575_cb: RequestIO: Out of resource > Jan 15 22:45:05 knuth kernel: cs: cb_free(bus 2) > -- > > I searched (not quite deeply, actually) in this mailing list archive but > found nothing about this problem... what's wrong with that? > > Ciao, > Illo. > > -- > ---------------------------------------------------------------------------- > Ilario Nardinocchi, illo@CS.UniBO.IT - Computer Science Adept since 1982 > illo@pypki.org - Oy gevalt, I'm so ferklempt that I > could plotz! > Know-nothing-bozo rule: > The views expressed above are entirely mine and do not represent the views, > policy or understanding of any other person or official body. > ---------------------------------------------------------------------------- > > _______________________________________________ > vortex mailing list > vortex@scyld.com > http://www.scyld.com/mailman/listinfo/vortex From illo@pypki.org Tue, 16 Jan 2001 12:26:51 +0100 Date: Tue, 16 Jan 2001 12:26:51 +0100 From: Illo de' Illis illo@pypki.org Subject: [vortex] 3c575_cb.c and the 3CXFEM656C CardBus PCMCIA On Tue, Jan 16, 2001 at 11:39:30AM +1100, Andrew Morton wrote: > Not good. > > Could you please go back to the first combination (kernel Cardbus+3c59x) and > send the `dmesg' output. Also, run `lspci -vvxx' and send the output > which relates to the 3c656. > > David may be able to suggest why the cardservices layer can't allocate the > I/O space? OK, I've tried the configuration with Linux v2.4.0-ac9+cardbus and 3c59x Here is the kernel output after card insertion: -- Jan 16 12:03:44 knuth kernel: cs: IO port probe 0x0c00-0x0cff: clean. Jan 16 12:03:44 knuth kernel: cs: IO port probe 0x0800-0x08ff: clean. Jan 16 12:03:44 knuth kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x3f8-0x3ff 0x408-0x40f 0x480-0x48f 0x4d0-0x4d7 Jan 16 12:03:44 knuth kernel: cs: IO port probe 0x0a00-0x0aff: clean. Jan 16 12:04:23 knuth kernel: cs: cb_alloc(bus 2): vendor 0x10b7, device 0x6564 Jan 16 12:04:23 knuth kernel: PCI: Failed to allocate resource 0 for PCI device 10b7:6564 Jan 16 12:04:23 knuth kernel: got res[10800000:1080007f] for resource 1 of PCI device 10b7:6564 Jan 16 12:04:23 knuth kernel: got res[10800080:108000ff] for resource 2 of PCI device 10b7:6564 Jan 16 12:04:23 knuth kernel: got res[10400000:1041ffff] for resource 6 of PCI device 10b7:6564 Jan 16 12:04:23 knuth kernel: PCI: Enabling device 02:00.0 (0000 -> 0003) Jan 16 12:04:23 knuth kernel: PCI: No IRQ known for interrupt pin A of device 02:00.0. Please try using pci=biosirq. Jan 16 12:04:23 knuth kernel: PCI: Failed to allocate resource 0 for PCI device 10b7:6565 Jan 16 12:04:23 knuth kernel: got res[10800100:108001ff] for resource 1 of PCI device 10b7:6565 Jan 16 12:04:23 knuth kernel: got res[10800200:1080027f] for resource 2 of PCI device 10b7:6565 Jan 16 12:04:23 knuth kernel: PCI: Enabling device 02:00.1 (0000 -> 0003) Jan 16 12:04:23 knuth kernel: PCI: No IRQ known for interrupt pin A of device 02:00.1. Please try using pci=biosirq. Jan 16 12:06:39 knuth kernel: 3c59x.c:LK1.1.12 06 Jan 2000 Donald Becker and others. http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $ Jan 16 12:06:39 knuth kernel: See Documentation/networking/vortex.txt Jan 16 12:06:39 knuth kernel: eth0: 3Com PCI 3CXFEM656C Tornado+Winmodem CardBus at 0x1000, PCI: Setting latency timer of device 02:00.0 to 64 Jan 16 12:06:39 knuth kernel: ff:ff:ff:ff:ff:ff, IRQ 9 Jan 16 12:06:39 knuth kernel: product code 'ÿÿ' rev ffff.15 date 15-31-127 Jan 16 12:06:39 knuth kernel: eth0: CardBus functions mapped 10800080->c8865080 Jan 16 12:06:39 knuth kernel: Full duplex capable Jan 16 12:06:39 knuth kernel: 1024K word-wide RAM 3:5 Rx:Tx split, autoselect/ interface. Jan 16 12:06:39 knuth kernel: Enabling bus-master transmits and early receives. -- (it seems that 0xff is all the driver can read from the device) When I try to do a ifconfig eth0 up it says eth0: command 0x5800 did not complete! Status=0xffff eth0: command 0x2800 did not complete! Status=0xffff And the output of lspci -v is: -- 02:00.0 Ethernet controller: 3Com Corporation 3CCFEM656 [id 6564] Cyclone CardBus (rev 10) Subsystem: 3Com Corporation: Unknown device 656c Flags: bus master, medium devsel, latency 64, IRQ 9 I/O ports at 1000 Memory at 10800000 (32-bit, non-prefetchable) [size=128] Memory at 10800080 (32-bit, non-prefetchable) [size=128] Expansion ROM at 10400000 [size=128K] Capabilities: [50] Power Management version 2 02:00.1 Communication controller: 3Com Corporation: Unknown device 6565 (rev 10) Subsystem: 3Com Corporation: Unknown device 656c Flags: medium devsel, IRQ 9 I/O ports at 1000 Memory at 10800100 (32-bit, non-prefetchable) [size=256] Memory at 10800200 (32-bit, non-prefetchable) [size=128] Capabilities: [50] Power Management version 2 -- And another (quasi-off-topic) thing: when I use the kernel 2.4.0 cardbus features, I have to insert a card two times in a row for it to be detected... it doesn't happen with the external PCMCIA package. Ciao, Illo. -- ---------------------------------------------------------------------------- Ilario Nardinocchi, illo@CS.UniBO.IT - Computer Science Adept since 1982 illo@pypki.org - Oy gevalt, I'm so ferklempt that I could plotz! Know-nothing-bozo rule: The views expressed above are entirely mine and do not represent the views, policy or understanding of any other person or official body. ---------------------------------------------------------------------------- From smunaut@student.fsa.ucl.ac.be Tue, 16 Jan 2001 13:22:55 +0100 Date: Tue, 16 Jan 2001 13:22:55 +0100 From: Munaut Sylvain smunaut@student.fsa.ucl.ac.be Subject: [vortex] [Fwd: 3c59x Driver] --------------000807040602040602040905 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I send this to D.Becker and he suggest me to send this report to you -------- Original Message -------- Subject: 3c59x Driver Date: Mon, 15 Jan 2001 22:37:30 +0100 From: Munaut Sylvain To: becker@scyld.com Hello, I have a problem with the 3c59x driver written by you in the 2.4.0 final kernel. When in do modprobe 3c59x it say that all is ok and tell me the MAC address and that the IRQ is also used by other device (my UHCI USB controller). And when i try an ifconfig eth0 10.0.0.246 netmask ..... I got two message that tell me that a command coul'nt be completed and return me two error message.And of course i can't access network. I've tried many option and try to find something interesting with vortex-diag and mii-diag but the only thing i found out is just before the ifconfig, mii diag tell the link is ok and active, after the ifconfig, it tell me that link is down ... if i do an ifdown, it tell me that the link has been broken and is now ok ... I've tried with two different network card (same model) and with 3 version of kenrel (2.4 final 2.4 test 6 and 2.4 test 10) and it doesn't work (but the card is ok since it work under a 2.2 kernel or Windows) My exact config : 3Com 3C905CX TX-M WOL Linux kernel 2.4.0 on RedHat 7 Asus A7V Mother board with TBird Athlon If you want additionnal data, like log og dmesg or exact debug info from the module or output of diag prog, just ask. In the hope that you have enough time to have a look on my problem Tanx, Munaut Sylvain --------------000807040602040602040905 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
I send this to D.Becker and he suggest me to send this report to you

-------- Original Message --------
Subject: 3c59x Driver
Date: Mon, 15 Jan 2001 22:37:30 +0100
From: Munaut Sylvain <smunaut@student.fsa.ucl.ac.be>
To: becker@scyld.com
 


Hello,

I have a problem with the 3c59x driver written by you in the 2.4.0 final 
kernel.

When in do modprobe 3c59x it say that all is ok and tell me the MAC 
address and that the IRQ is also used by other device (my UHCI USB 
controller).

And when i try an ifconfig eth0 10.0.0.246 netmask ..... I got two 
message that tell me that a command coul'nt be completed and return me 
two error message.And of course i can't access network.

I've tried many option and try to find something interesting with 
vortex-diag and mii-diag but the only thing i found out is just before 
the ifconfig, mii diag tell the link is ok and active, after the 
ifconfig, it tell me that link is down ... if i do an ifdown, it tell me 
that the link has been broken and is now ok ...

I've tried with two different network card (same model) and with 3 
version of kenrel (2.4 final 2.4 test 6 and 2.4 test 10) and it doesn't 
work (but the!
 card is ok since it work under a 2.2 kernel or Windows)

My exact config :
  3Com 3C905CX TX-M WOL
  Linux kernel 2.4.0 on RedHat 7
  Asus A7V Mother board with TBird Athlon

If you want additionnal data, like log og dmesg or exact debug info from 
the module or output of diag prog, just ask.

In the hope that you have enough time to have a look on my problem

Tanx,
Munaut Sylvain





--------------000807040602040602040905-- From illo@pypki.org Wed, 17 Jan 2001 01:32:27 +0100 Date: Wed, 17 Jan 2001 01:32:27 +0100 From: Illo de' Illis illo@pypki.org Subject: [vortex] 3c575_cb.c and the 3CXFEM656C CardBus PCMCIA On Tue, Jan 16, 2001 at 12:26:51PM +0100, Illo de' Illis wrote: > On Tue, Jan 16, 2001 at 11:39:30AM +1100, Andrew Morton wrote: > > Not good. > > > > Could you please go back to the first combination (kernel Cardbus+3c59x) and > > send the `dmesg' output. Also, run `lspci -vvxx' and send the output > > which relates to the 3c656. > > > > David may be able to suggest why the cardservices layer can't allocate the > > I/O space? > > OK, I've tried the configuration with Linux v2.4.0-ac9+cardbus and 3c59x > Here is the kernel output after card insertion: [...] I've just tried with Linux 2.2.18+PCMCIA 3.1.23 and it behaves the same: -- Jan 17 01:24:15 knuth kernel: cs: cb_alloc(bus 32): vendor 0x10b7, device 0x6564 Jan 17 01:24:15 knuth cardmgr[154]: initializing socket 0 Jan 17 01:24:15 knuth cardmgr[154]: socket 0: 3Com 3CXFEM656C w/Winmodem Jan 17 01:24:15 knuth cardmgr[154]: executing: 'modprobe cb_enabler' Jan 17 01:24:16 knuth kernel: cb_enabler.c 1.31 2000/06/12 21:29:36 (David Hinds) Jan 17 01:24:16 knuth cardmgr[154]: executing: 'modprobe 3c575_cb' Jan 17 01:24:16 knuth kernel: 3c59x.c:v0.99Q 5/16/2000 Donald Becker, becker@scyld.com Jan 17 01:24:16 knuth kernel: http://www.scyld.com/network/vortex.html Jan 17 01:24:16 knuth kernel: register_driver('3c575_cb') Jan 17 01:24:16 knuth kernel: ds: register_pccard_driver('3c575_cb') Jan 17 01:24:16 knuth kernel: cb_attach(0) Jan 17 01:24:16 knuth kernel: cb_event(0x000004) Jan 17 01:24:16 knuth kernel: cb_config(0xc71e2900) Jan 17 01:24:16 knuth kernel: cs: cb_config(bus 32) Jan 17 01:24:16 knuth kernel: cs: could not allocate 512 IO ports for CardBus socket 0 Jan 17 01:24:16 knuth kernel: cs: cb_release(bus 32) Jan 17 01:24:16 knuth kernel: 3c575_cb: RequestIO: Out of resource Jan 17 01:24:17 knuth cardmgr[154]: get dev info on socket 0 failed: Resource temporarily unavailable Jan 17 01:24:17 knuth kernel: cb_detach(0xc71e2900) Jan 17 01:24:17 knuth kernel: cb_release(0xc71e2900) Jan 17 01:25:33 knuth kernel: cs: cb_free(bus 32) Jan 17 01:25:33 knuth cardmgr[154]: shutting down socket 0 Jan 17 01:25:33 knuth cardmgr[154]: executing: 'modprobe -r 3c575_cb' Jan 17 01:25:33 knuth kernel: unregister_driver('3c575_cb') Jan 17 01:25:33 knuth kernel: ds: unregister_pccard_driver('3c575_cb') Jan 17 01:25:33 knuth kernel: cb_enabler: unloading Jan 17 01:25:33 knuth cardmgr[154]: executing: 'modprobe -r cb_enabler' -- I'm pretty amazed... I've tried with two other identical cards from a friend of mine who has plenty of them and uses them with Windoze, and they behave the same. So the card is ok.... Ciao, Illo. -- ---------------------------------------------------------------------------- Ilario Nardinocchi, illo@CS.UniBO.IT - Computer Science Adept since 1982 illo@pypki.org - Oy gevalt, I'm so ferklempt that I could plotz! Know-nothing-bozo rule: The views expressed above are entirely mine and do not represent the views, policy or understanding of any other person or official body. ---------------------------------------------------------------------------- From illo@pypki.org Wed, 17 Jan 2001 02:52:03 +0100 Date: Wed, 17 Jan 2001 02:52:03 +0100 From: Illo de' Illis illo@pypki.org Subject: [vortex] partially solved [was: 3c575_cb.c and the 3CXFEM656C CardBus PCMCIA] I got the card running with the 3c575_cb driver by adding the line include port 0x1000-0x17ff in /etc/pcmcia/config.opts. I just realized it could be the right choice when, while trying to make it work with the 3c59x driver, the kernel told me it was allocating I/O ports at 0x1000-0x10ff and 0x1100-0x11ff... The card doesn't work with the 3c59x driver yet. Ciao, Illo. -- ---------------------------------------------------------------------------- Ilario Nardinocchi, illo@CS.UniBO.IT - Computer Science Adept since 1982 illo@pypki.org - Oy gevalt, I'm so ferklempt that I could plotz! Know-nothing-bozo rule: The views expressed above are entirely mine and do not represent the views, policy or understanding of any other person or official body. ---------------------------------------------------------------------------- From madden@fracas.cs.berkeley.edu Tue, 16 Jan 2001 20:29:44 -0800 Date: Tue, 16 Jan 2001 20:29:44 -0800 From: Samuel Madden madden@fracas.cs.berkeley.edu Subject: [vortex] 3C905CX, 2.2.18, Dell Dimension 4100 (P933) Receive Failure Fix / Inquiry Setting up Debian on a Dell Dimension 4100 with a P3/933 under 2.2.18. The 3c59x module would load and send data without error, but didn't seem to ever receive packets. I applied the patches suggested in: http://www.scyld.com/pipermail/vortex/2000-December/000858.html To no avail. However, in reading through these posts it became clear that the driver is extremely sensistive to various timer-loops in the code, especially with newer drivers. It also struck me that for-loops will stall for different amounts of time depending on the processor, while the timeouts of the network card probably don't vary with cpu speed. So, I tried increasing the timeouts in vortex_rx and was able to get the driver to work (see diff dump below). I'm wondering: 1) why isn't some more precise timing mechanism being used here? 2) what are the performance implications of making the rx timeouts significantly higher? 3) does anyone have suggestions for what optimal values might be here? i've increased them quite a lot and am not really interesting in trying all the permuations manually. Here's the diff -- note that this includes some changes from the message referenced above -- they may or may not be neccessary. File: 3c59x.c 26c26 < "3c59x.c:v0.99Rb 8/8/2000 Donald Becker, becker@scyld.com, SRM 1.16.01\n"; --- > "3c59x.c:v0.99Rb 8/8/2000 Donald Becker, becker@scyld.com\n"; 897c897 < mdio_sync(ioaddr,32); --- > mii_preamble_required++; 899,900c899,900 < for (phy = 0; phy <= 32 && phy_idx < 1; phy++) { < int mii_status, phyx = (phy == 0 ? 24 : phy == 24 ? 0 : phy); --- > for (phy = 1; phy <= 32 && phy_idx < sizeof(vp->phys); phy++) { > int mii_status, phyx = phy & 0x1f; 1159c1159 < for (i = 500000; i >= 0 ; i--) --- > for (i = 2000; i >= 0 ; i--) 1165,1166c1165 < for (i=500000; i >= 0; i--) < /* for (i = 2000; i >= 0 ; i--) */ --- > for (i = 2000; i >= 0 ; i--) 1624c1623 < for (i = 6000; i >= 0 ; i--) --- > for (i = 600; i >= 0 ; i--) 1841c1840 < for (i = 5000; i >= 0; i--) --- > for (i = 200; i >= 0; i--) 1852c1851 < for (i = 5000; i >= 0; i--) --- > for (i = 200; i >= 0; i--) -Sam Madden UC Berkeley Database Group madden@cs.berkeley.edu From becker@scyld.com Wed, 17 Jan 2001 00:36:27 -0500 (EST) Date: Wed, 17 Jan 2001 00:36:27 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [vortex] 3C905CX, 2.2.18, Dell Dimension 4100 (P933) Receive Failure Fix / Inquiry On Tue, 16 Jan 2001, Samuel Madden wrote: > However, in reading through these posts it became clear that the driver > is extremely sensistive to various timer-loops in the code, especially with > newer drivers. It also struck me that for-loops will stall for different > amounts of time depending on the processor, while the timeouts of the > network card probably don't vary with cpu speed. So, I tried increasing > the timeouts in vortex_rx and was able to get the driver to work (see diff > dump below). You misunderstand the loops. They are not software timing loops. They are PCI transaction counts. PCI transactions are often the most appropriate measure. > I'm wondering: > 1) why isn't some more precise timing mechanism being used here? Most of the operations should take zero apparent time. I check the loop count for all operations when I write a driver, and it's rare that a chip actually requires more than one loop iteration. The loop counts exist to make certain the driver doesn't hang on broken or missing hardware. > 2) what are the performance implications of making the rx timeouts > significantly higher? Bad. The kernel is sitting in a very long timing loop. In some cases this occurs with many interrupts blocked due to rotating interrupt priority. The patches that increase the timing loop counts are for experimental and verification purposes only. Please do not submit them for inclusion in a main-line kernel! > 3) does anyone have suggestions for what optimal values might be here? i've > increased them quite a lot and am not really interesting in trying > all the permuations manually. Not for the CX board -- some aspect of the design appears to have changed dramatically from the earlier chips. 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 From andrewm@uow.edu.au Wed, 17 Jan 2001 20:00:43 +1100 Date: Wed, 17 Jan 2001 20:00:43 +1100 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] [Fwd: 3c59x Driver] Munaut Sylvain wrote: > > I have a problem with the 3c59x driver written by you in the 2.4.0 final > kernel. Yep. The 3c905CX is subtly different from its predecessors. A fix is present in the 2.4.1-pre1 kernel, however I would not recommend (even a tiny bit) that you upgrade beyond 2.4.1.pre3 :( There's a driver at http://www.uow.edu.au/~andrewm/linux/ which has the change. I suggest you use that driver within 2.4.0. From joe@netli.com Wed, 17 Jan 2001 02:03:02 -0800 Date: Wed, 17 Jan 2001 02:03:02 -0800 From: Joe Rouvier joe@netli.com Subject: [vortex] 3C905CX, 2.2.18, Dell Dimension 4100 (P933) ReceiveFailure Fix / Inquiry Donald Becker wrote: > > On Tue, 16 Jan 2001, Samuel Madden wrote: > [...] > You misunderstand the loops. They are not software timing loops. They > are PCI transaction counts. PCI transactions are often the most > appropriate measure. > > > I'm wondering: > > 1) why isn't some more precise timing mechanism being used here? > > Most of the operations should take zero apparent time. I check the loop > count for all operations when I write a driver, and it's rare that a > chip actually requires more than one loop iteration. If it's rare for a device to take more than one PCI transaction to do something, do you think the ~30000 transaction count for RxReset on the 3c905cx means the current driver doesn't init the card correctly? Or is the new chip just slow on that command? > The loop counts exist to make certain the driver doesn't hang on broken > or missing hardware. > > > 2) what are the performance implications of making the rx timeouts > > significantly higher? > > Bad. The kernel is sitting in a very long timing loop. In some cases > this occurs with many interrupts blocked due to rotating interrupt > priority. But the longer loop is only used on TxReset, RxReset, TotalReset, DownStall and RxDiscard. Aren't these commands sent very rarely? (referring specifically to the 2.2.19-pre2 driver with Adam M's wait_for_completion() changes) > The patches that increase the timing loop counts are for experimental > and verification purposes only. Please do not submit them for > inclusion in a main-line kernel! > > > 3) does anyone have suggestions for what optimal values might be here? i've > > increased them quite a lot and am not really interesting in trying > > all the permuations manually. > > Not for the CX board -- some aspect of the design appears to have > changed dramatically from the earlier chips. I recently purchased 6 of the Dells with this card. We will be writing networking software on 'em. This tends to make having a reliable NIC kind of nice. Should I yank the cards and get something else? If so, any recommendations? I don't suppose anyone has heard anything from 3com? ----- "Computer games don't affect kids, I mean if pac man affected us as kids, we'd all be running around in darkened rooms, munching pills and listening to repetitive music." --Unknown From andrewm@uow.edu.au Thu, 18 Jan 2001 01:00:33 +1100 Date: Thu, 18 Jan 2001 01:00:33 +1100 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] 3C905CX, 2.2.18, Dell Dimension 4100 (P933) ReceiveFailure Fix / Inquiry Joe Rouvier wrote: > > If it's rare for a device to take more than one PCI transaction to do > something, do you think the ~30000 transaction count for RxReset on the > 3c905cx means the current driver doesn't init the card correctly? Or is > the new chip just slow on that command? > The code in 2.2.19-pre does (I think) 2,000 PCI transactions back-to-back. Then it falls back to one PCI read per 10 microseconds, so it's not too bad. This is basically what 3com's own driver does, which is presumably what their windows driver does. freebsd just does a "what the heck" 100 millisecond pause. I do intend to instrument 3com's linux driver, see if that is also pausing for 30 milliseconds. If it is, then we're presumably not doing anything wrong in the initialisation. The device simply changed. From bogdan.costescu@iwr.uni-heidelberg.de Wed, 17 Jan 2001 16:21:29 +0100 (CET) Date: Wed, 17 Jan 2001 16:21:29 +0100 (CET) From: Bogdan Costescu bogdan.costescu@iwr.uni-heidelberg.de Subject: [vortex] 3C905CX, 2.2.18, Dell Dimension 4100 (P933) ReceiveFailure Fix / Inquiry On Wed, 17 Jan 2001, Joe Rouvier wrote: > If it's rare for a device to take more than one PCI transaction to do > something, do you think the ~30000 transaction count for RxReset on the > 3c905cx means the current driver doesn't init the card correctly? Or is > the new chip just slow on that command? The latter. For some reason, the 3Com engineers decided that the RxReset command should take longer. 3Com's driver (3c90x) waits up to 1 second for _any_ command to complete (I'm talking here only about the commands that need to be waited for); their Windows driver does the same. > But the longer loop is only used on TxReset, RxReset, TotalReset, > DownStall and RxDiscard. Aren't these commands sent very rarely? > (referring specifically to the 2.2.19-pre2 driver with Adam M's > wait_for_completion() changes) Not all commands need to be waited for. For example, when a DownStall command comes, the NIC might just be in the middle of the download procedure, so it has to finish this first and then go into the stall-ed state. The opposite command (DownUnstall) doesn't have any such constraint and is effective immediately. The *Reset commands are supposed to be sent very rarely, indeed. But DownStall is sent for every queued Tx packet, which is very often (at least in the non-polling mode). > I recently purchased 6 of the Dells with this card. We will be writing > networking software on 'em. This tends to make having a reliable NIC > kind of nice. Should I yank the cards and get something else? If so, > any recommendations? I don't personally have such cards, but from the reports up to now, it seems like the RxReset timing is the only thing which has changed w.r.t. the older 905C cards - which I have and are very reliable. Sincerely, Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From becker@scyld.com Wed, 17 Jan 2001 09:16:07 -0500 (EST) Date: Wed, 17 Jan 2001 09:16:07 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [vortex] 3C905CX, 2.2.18, Dell Dimension 4100 (P933) ReceiveFailure Fix / Inquiry On Wed, 17 Jan 2001, Joe Rouvier wrote: > Donald Becker wrote: > > Most of the operations should take zero apparent time. I check the loop > > count for all operations when I write a driver, and it's rare that a > > chip actually requires more than one loop iteration. > > If it's rare for a device to take more than one PCI transaction to do > something, do you think the ~30000 transaction count for RxReset on the > 3c905cx means the current driver doesn't init the card correctly? Or is > the new chip just slow on that command? My _guess_ is some designer took the easy way out when writing the internal firmware. Rather than reset the receive logic, they just turned off the reciever and started a timing loop that would be long enough to be certain that the chip was no longer active. > But the longer loop is only used on TxReset, RxReset, TotalReset, > DownStall and RxDiscard. Aren't these commands sent very rarely? > (referring specifically to the 2.2.19-pre2 driver with Adam M's > wait_for_completion() changes) They might be rare in some usage, but not in all. A machine that does ifdown eth0; ; ifup eth0 would see the long delay very frequently. > I don't suppose anyone has heard anything from 3com? Just that it will be several weeks before the manual is available. 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 From steve@fractalus.com Mon, 22 Jan 2001 14:22:05 -0500 (EST) Date: Mon, 22 Jan 2001 14:22:05 -0500 (EST) From: SteveC steve@fractalus.com Subject: [vortex] 3Com 920? Hi list, I've been asked to install linux on a brand new Dell box with an on motherboard 3Com 920. Can't find anywhere that it is supported and searched the mailing list archive. /proc/pci entry goes a little like this (hand copied) Bus 2, device 12, function 0: Ethernet controller: 3Com Unknown device (rev120). Vendor id=10b7. Device id=9200. Medium devsel. IRQ 5. Master Capable. Latency=64. Min Gnt=10.Max Lat=10. I/O at 0xe880 [0xe881]. Non-prefetchable 32 bit memory at 0xfaffec00 [0xfaffec00] If it is supported can anyone give me some options to throw at the driver? Doing a fresh debian install here. If unsupported then I'll pull it apart and throw in a crusty ne2000 or something thanks for your time! have fun, pub 1024D/A9D75E73 2000-05-30 Stephen Coast (SteveC) [expires:2001-05-30] www.fractalus.com/steve/ From morton@nortelnetworks.com Tue, 23 Jan 2001 01:03:34 +0000 Date: Tue, 23 Jan 2001 01:03:34 +0000 From: Andrew Morton morton@nortelnetworks.com Subject: [vortex] 3Com 920? SteveC wrote: > > Hi list, > > I've been asked to install linux on a brand new Dell box with an on > motherboard 3Com 920. That's a 3c905C, after a bout of gratuitous product renaming disease. It works just fine with all known Linux drivers :) From steve@fractalus.com Tue, 23 Jan 2001 08:57:24 -0500 (EST) Date: Tue, 23 Jan 2001 08:57:24 -0500 (EST) From: SteveC steve@fractalus.com Subject: [vortex] 3Com 920? On Tue, 23 Jan 2001, Andrew Morton wrote: > That's a 3c905C, after a bout of gratuitous product renaming disease. > It works just fine with all known Linux drivers :) Thanks - and thanks to the guy noting his Dell 420. Strange but the debian install disk/cd lists seperate drivers for the 3c905 - and about 4 others - not a combined driver - and none of them work. install and compile my kernel and it works though... have fun, pub 1024D/A9D75E73 2000-05-30 Stephen Coast (SteveC) [expires:2001-05-30] www.fractalus.com/steve/ From andrewm@uow.edu.au Wed, 24 Jan 2001 00:14:48 +1100 Date: Wed, 24 Jan 2001 00:14:48 +1100 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] 3Com 920? SteveC wrote: > > On Tue, 23 Jan 2001, Andrew Morton wrote: > > That's a 3c905C, after a bout of gratuitous product renaming disease. > > It works just fine with all known Linux drivers :) > > Thanks - and thanks to the guy noting his Dell 420. > > Strange but the debian install disk/cd lists seperate drivers for the > 3c905 - and about 4 others - not a combined driver - and none of them > work. install and compile my kernel and it works though... That's odd. Which kernels did not work, and which ones did work? Thanks. From fannberg@netmedia.de Tue, 23 Jan 2001 17:56:47 +0100 Date: Tue, 23 Jan 2001 17:56:47 +0100 From: Kjartan Fannberg fannberg@netmedia.de Subject: [vortex] network slow w/25% Broadcasts Hello Let's do it the other way round for better "relevance filtering": Question: Does/can a data:broadcast frame ratio of about 3:1 (sending, along with 5% multicast and a few collisions) hint at a specific problem? Background: Network is slow, setup is linux-switch-linux, both computers Athlon > 500MHz, but allowing a margin also can occur with PentiumIII and/or any of linux-linux (crossover-cable) or linux-windows (with or without switch). We are using 3c905C-TX and -TX-M cards, switch is a 10/100Mbit (Allied Telesyn ATS-8224XL), total netload is very low (switch backbone runs at maybe 5-10% load when net is busy). Sometimes looks like negotiation tends to fail, both auto and "fixed" (100Mbit/full-duplex/flow-control), usually the full-duplex setting. Sometimes all "ends" show 100Mbit full-duplex, but speed varies from 11MB/s to 100kB/s and CPU-load tops (even on a 1GHz Athlon) during ftp transfers and collisions, though not very frequent, DO occur. Diag-Tools (mii-diag/vortex-diag) don't agree (mii: full-duplex, vortex: half-duplex) and setting with mii-diag doesn't change netspeed nor the output of vortex-diag. 3c59x on 2.2.16-kernel sometimes works fine, but in a case after upgrading mainboard/CPU (still Athlon) suddenly shows same symptoms. Sending along module parameters not always fixes it and has no effect with 3c90x. The worst is that I sometimes cannot reproduce some specific behavior. Two identical computers get two identical cards, connected to each other ONE switches to FD, the other obviously doesn't and won't. And a "less urgent" question: interface is down, module unloaded. When I reload it with different options, sometimes they show no effect. Only rebooting seems to get the job done. What did I do wrong? Thanks - at least for reading THIS far ;) Kjartan Fannberg _____________________________________________ fannberg@netmedia.de, http://www.netmedia.de netmedia GmbH Neugrabenweg 5-7 66123 Saarbruecken Germany fon: +49 (0) 681 / 3 79 88 - 0 fax: +49 (0) 681 / 3 79 88 - 99 From andreas@ind.RWTH-Aachen.DE Wed, 24 Jan 2001 03:19:04 +0100 Date: Wed, 24 Jan 2001 03:19:04 +0100 From: Andreas Welbers andreas@ind.RWTH-Aachen.DE Subject: [vortex] Problem with 3c59x, kernel-2.4 and 3C980C --------------FBB78446AF0560BEFC876F67 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I have problems with kernel-2.4.0 and the 3c59x.c driver. Systems starts up, but some times it crashes while heavy network load. My system: Dual-PIII, 3C980C-TXM, Kernel-2.4.0-ac9 On console I get the following error message: eth0: Transmit error, Tx status register 82. Flags; bus-master 1, full 0; dirty 17126(6) current 17126(6). Transmit list 00000000 vs. f72c0260. 0: @f72c0200 length 800005ea status 000105ea 1: @f72c0210 length 800005ea status 000105ea 2: @f72c0220 length 800005ea status 000105ea 3: @f72c0230 length 800005ea status 000105ea 4: @f72c0240 length 800005ea status 000105ea 5: @f72c0250 length 800005ea status 800105ea 6: @f72c0260 length 800000ff status 000100ff 7: @f72c0270 length 80000042 status 00010042 8: @f72c0280 length 80000042 status 00010042 9: @f72c0290 length 80000056 status 00010056 10: @f72c02a0 length 800000ff status 000100ff 11: @f72c02b0 length 80000044 status 00010044 12: @f72c02c0 length 800005ea status 000105ea 13: @f72c02d0 length 800005ea status 000105ea 14: @f72c02e0 length 800005ea status 000105ea 15: @f72c02f0 length 800005ea status 000105ea I tried different versions of 3c59x and the patched kernel from Alan Cox in version '-ac9'. The latest driver I tried was '3c59x.c:LK1.1.12 06 Jan 2001'. The drivers from 3Com itself, 3c90x-1.0.0i, can't be compiled for the new kernel. Any idea or help? Thanks, Andreas -- (Where there's a Linux, there's a way!) ===== ANDREAS WELBERS === eMail: andreas@ind.rwth-aachen.de ======= Office: Institut fuer Nachrichtengeraete und Datenverarbeitung (IND) Muffeter Weg 3, 52072 Aachen, Germany fon: +49/241/806962 fax: +49/241/8888186 w3: http://www.ind.rwth-aachen.de/~andreas ==========================/\/\/\/\/\/\/\/\========================= --------------FBB78446AF0560BEFC876F67 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello,

I have problems with kernel-2.4.0 and the 3c59x.c driver. Systems starts up, but
some times it crashes while heavy network load.

My system: Dual-PIII, 3C980C-TXM, Kernel-2.4.0-ac9

On console I get the following error message:

eth0: Transmit error, Tx status register 82.
  Flags; bus-master 1, full 0; dirty 17126(6) current 17126(6).
  Transmit list 00000000 vs. f72c0260.
  0: @f72c0200  length 800005ea status 000105ea
  1: @f72c0210  length 800005ea status 000105ea
  2: @f72c0220  length 800005ea status 000105ea
  3: @f72c0230  length 800005ea status 000105ea
  4: @f72c0240  length 800005ea status 000105ea
  5: @f72c0250  length 800005ea status 800105ea
  6: @f72c0260  length 800000ff status 000100ff
  7: @f72c0270  length 80000042 status 00010042
  8: @f72c0280  length 80000042 status 00010042
  9: @f72c0290  length 80000056 status 00010056
  10: @f72c02a0  length 800000ff status 000100ff
  11: @f72c02b0  length 80000044 status 00010044
  12: @f72c02c0  length 800005ea status 000105ea
  13: @f72c02d0  length 800005ea status 000105ea
  14: @f72c02e0  length 800005ea status 000105ea
  15: @f72c02f0  length 800005ea status 000105ea

I tried different versions of 3c59x and the patched kernel from Alan Cox in version
'-ac9'. The latest driver I tried was '3c59x.c:LK1.1.12 06 Jan 2001'.
 

The drivers from 3Com itself, 3c90x-1.0.0i,  can't be compiled for the new kernel.

Any idea or help?

Thanks,

Andreas 

-- 
(Where there's a Linux, there's a way!)

===== ANDREAS WELBERS === eMail: andreas@ind.rwth-aachen.de =======
Office: Institut fuer Nachrichtengeraete und Datenverarbeitung (IND)
        Muffeter Weg 3, 52072 Aachen, Germany
        fon: +49/241/806962     fax: +49/241/8888186
        w3: http://www.ind.rwth-aachen.de/~andreas
==========================/\/\/\/\/\/\/\/\=========================
  --------------FBB78446AF0560BEFC876F67-- From andrewm@uow.edu.au Wed, 24 Jan 2001 15:01:15 +1100 Date: Wed, 24 Jan 2001 15:01:15 +1100 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] Problem with 3c59x, kernel-2.4 and 3C980C Andreas Welbers wrote: > > eth0: Transmit error, Tx status register 82. This is described at http://www.scyld.com/network/vortex.html. It's usually caused by duplex problems. If you think you should be running full duplex then please follow the steps described in the last section of Documentation/vortex.txt. The mii-diag and vortex-diag output would be interesting, as would be a description of your network setup. Thanks. From andrewm@uow.edu.au Wed, 24 Jan 2001 17:23:47 +1100 Date: Wed, 24 Jan 2001 17:23:47 +1100 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] network slow w/25% Broadcasts Kjartan Fannberg wrote: > > Hello > > Let's do it the other way round for better "relevance filtering": > > Question: > > Does/can a data:broadcast frame ratio of about 3:1 (sending, along with 5% > multicast and a few collisions) hint at a specific problem? Not really. This driver handles multicast by going promiscuous, so there will be some extra load... > Background: > I does sound like duplex problems. Try to find a consistent, repeatable failure and send us the output of vortex-diag and mii-diag, as described in http://www.uow.edu.au/~andrewm/linux/vortex.txt Thanks. From becker@scyld.com Wed, 24 Jan 2001 02:08:13 -0500 (EST) Date: Wed, 24 Jan 2001 02:08:13 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [vortex] network slow w/25% Broadcasts On Wed, 24 Jan 2001, Andrew Morton wrote: > > Does/can a data:broadcast frame ratio of about 3:1 (sending, along with 5% > > multicast and a few collisions) hint at a specific problem? > > Not really. This driver handles multicast by going promiscuous, so > there will be some extra load... I think that Andrew meant to say that the driver doesn't use the questionable hardware multicast filter, but that it put the receiver into the Rx-all-multicast mode. Not that it switches into promiscuous mode for non-multicast packets. 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 From vherva@mail.niksula.cs.hut.fi Wed, 24 Jan 2001 11:05:44 +0200 Date: Wed, 24 Jan 2001 11:05:44 +0200 From: Ville Herva vherva@mail.niksula.cs.hut.fi Subject: [vortex] Problem with Nokia ADSL modem/hub and 3c905 I have a Nokia ADSL modem with 4 10MBit ethernet ports. I have a linux 2.2.18 box with one 3c905A connected to it. If I unplug the network cable from the Nokia box and try to plug it back, the link leds stay off. If If boot the Nokia box, the leds are on, but the connection won't work. The Nokia box doesn't answer arp etc. If I now boot the Linux machine, everything works again. I've tried ifuping and ifdowning the interface, rmmodding and insmodding the 3c59x module etc, to no avail. While this is most likely a Nokia ADSL box bug, but since I'm unable to debug or tweak it, I would be interested to know if there is anything I can try at the 3c59x end. It is frustrating to have to boot the linux box everytime there is a problem with the ADSL connection. What might cause this? I'm guessing somekind of duplex negotiation failure. The 3c59x reports autoselect/MII media regardless of whether the connection is working or not. -- v -- v@iki.fi From andrewm@uow.edu.au Wed, 24 Jan 2001 20:51:04 +1100 Date: Wed, 24 Jan 2001 20:51:04 +1100 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] Problem with Nokia ADSL modem/hub and 3c905 Ville Herva wrote: > > I have a Nokia ADSL modem with 4 10MBit ethernet ports. I have a > linux 2.2.18 box with one 3c905A connected to it. If I unplug the > network cable from the Nokia box and try to plug it back, the link leds > stay off. If If boot the Nokia box, the leds are on, but the connection > won't work. The Nokia box doesn't answer arp etc. If I now boot the Linux > machine, everything works again. > > I've tried ifuping and ifdowning the interface, rmmodding and insmodding > the 3c59x module etc, to no avail. I was about to guess that your problem is to do with the interface selection logic - with that version of the driver, if it detects loss of the 10baseT connection it tries another interface type and gets stuck there. However, removing and reloading the driver should make it work again, so something odd is happening. The driver at http://www.uow.edu.au/~andrewm/linux/3c59x.c-2.2.19-pre6-1.gz has been changed so that when you force it to use a particular interface, then it simply does what you said. (What interfaces does the 3c905A actually have? I don't know). Could you please replace the existing 3c59x.c with the above file and rebuild the driver. Then, force it to use the 10baseT port with modprobe 3c59x options=0 and then test? If that doesn't work then could you please send a full report, along the following lines: 1: load the driver with `modprobe 3c59x debug=7' 2: ifup eth0 3: wait > one minute 4: unplug the interface 5: wait > one minute 6: reattach the interface 7: wait > 1 minute then send the logfiles along with the mii-diag and vortex-diag output when the interface is good and when it's bad. Instructions for this are at http://www.uow.edu.au/~andrewm/linux/vortex.txt If you can do all this, we'll get it fixed :) Thanks. From koos@kzdoos.xs4all.nl Wed, 24 Jan 2001 12:44:28 +0100 Date: Wed, 24 Jan 2001 12:44:28 +0100 From: Koos van den Hout koos@kzdoos.xs4all.nl Subject: [vortex] Problem with Nokia ADSL modem/hub and 3c905 Quoting Ville Herva who wrote on Wed, Jan 24, 2001 at 11:05:44AM +0200: > While this is most likely a Nokia ADSL box bug, but since I'm unable to > debug or tweak it, I would be interested to know if there is anything I > can try at the 3c59x end. It is frustrating to have to boot the linux box > everytime there is a problem with the ADSL connection. > > What might cause this? I'm guessing somekind of duplex negotiation > failure. > > The 3c59x reports autoselect/MII media regardless of whether the > connection is working or not. For exact details of what the state of the adapter is, you could try the vortex-diag util (with libmii!) from http://www.scyld.com/diag/index.html It helped me trace down a duplex problem to a (cheap) switch not negotiating the link completely with certain 3com cards. Koos -- Koos van den Hout, PGP keyid RSA/1024 0xCA845CB5 via keyservers koos@kzdoos.xs4all.nl or DSS/1024 0xF0D7C263 -?) Fax +31-30-2817051 Visit my site about books with reviews /\\ http://idefix.net/~koos/ http://www.virtualbookcase.com/ _\_V From vherva@mail.niksula.cs.hut.fi Wed, 24 Jan 2001 13:54:32 +0200 Date: Wed, 24 Jan 2001 13:54:32 +0200 From: Ville Herva vherva@mail.niksula.cs.hut.fi Subject: [vortex] Problem with Nokia ADSL modem/hub and 3c905 On Wed, Jan 24, 2001 at 08:51:04PM +1100, you [Andrew Morton] claimed: > Ville Herva wrote: > > > I was about to guess that your problem is to do with the interface > selection logic - with that version of the driver, if it detects loss > of the 10baseT connection it tries another interface type and gets stuck > there. > > However, removing and reloading the driver should make it work > again, so something odd is happening. That's what I figured, too. The odd thing however is that 1) when I unplug and replug the cable, the link leds go out and stay that way. 2) when I boot the ADSL box (and do nothing else, ie. I don't boot the linux box nor reinstall the modules), the link leds do _get_ lit, but the connections does not work. > The driver at http://www.uow.edu.au/~andrewm/linux/3c59x.c-2.2.19-pre6-1.gz > has been changed so that when you force it to use a particular interface, > then it simply does what you said. > > (What interfaces does the 3c905A actually have? I don't know). If you mean physical interfaces? Actually I'm not 100% sure, but I would imagine only RJ45. > Could you please replace the existing 3c59x.c with the above file > and rebuild the driver. Then, force it to use the 10baseT > port with > > modprobe 3c59x options=0 > > and then test? I tried different options (0,2,6 I think, but I'm not sure) with the 2.2.18pre19 3c59x I'm using... > If that doesn't work then could you please send a full report, along the > following lines: > > 1: load the driver with `modprobe 3c59x debug=7' > 2: ifup eth0 > 3: wait > one minute > 4: unplug the interface > 5: wait > one minute > 6: reattach the interface > 7: wait > 1 minute > > then send the logfiles along with the mii-diag and vortex-diag > output when the interface is good and when it's bad. Instructions > for this are at http://www.uow.edu.au/~andrewm/linux/vortex.txt > > If you can do all this, we'll get it fixed :) Ok. I'll do it as soon as I get home. I lost the uptime already when I had to boot yesterday to get the net working ;@/ thanks, -- v -- v@iki.fi From alex@x3ja.co.uk Wed, 24 Jan 2001 13:36:46 +0000 Date: Wed, 24 Jan 2001 13:36:46 +0000 From: Alex Walker alex@x3ja.co.uk Subject: [vortex] 3c900B-TPC I have been trying for a while to get my 3c900B working properly under Linux. I'm not even sure if it's a vortex card or not, so I apologise if this is the wrong place to post. I found some drivers from 3com (3c90x-1.0.0) which came with 2.0.36, 2.2.5 and 2.2.12 binaries and the source. I try compiling the source and I get a whole host of errors and no file gets output. Errors are mainly like: 3c90x.c:5149: dereferencing pointer to incomplete type (about 150 times) I can post them all to the list if you want to see them. I am running 2.4.0, with RedHat 7.0, with all errata installed on an i586. Any ideas on how I might get it to compile or on where to look for other drivers would be greatly appreciated. aLeX -- ----------------------------- Alex Walker alex@x3ja.co.uk x3ja|alex ----------------------------- From andrewm@uow.edu.au Thu, 25 Jan 2001 01:00:02 +1100 Date: Thu, 25 Jan 2001 01:00:02 +1100 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] 3c900B-TPC Alex Walker wrote: > > I found some drivers from 3com (3c90x-1.0.0) which came with 2.0.36, > ... > I am running 2.4.0, with RedHat 7.0, with all errata installed on an i586. 3c90x.c is only for 2.2 kernels. You should use drivers/net/3c59x.c, which is part of the 2.4.0 distribution. make menuconfig. Network Device Support -> Ethernet (10 or 100 Mbit) -> 3com cards -> 3c590/3c900 series (592/595/597) "Vortex/Boomerang" support From becker@scyld.com Wed, 24 Jan 2001 10:41:27 -0500 (EST) Date: Wed, 24 Jan 2001 10:41:27 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [vortex] Problem with Nokia ADSL modem/hub and 3c905 On Wed, 24 Jan 2001, Ville Herva wrote: > I have a Nokia ADSL modem with 4 10MBit ethernet ports. I have a > linux 2.2.18 box with one 3c905A connected to it. If I unplug the > network cable from the Nokia box and try to plug it back, the link leds > stay off. If If boot the Nokia box, the leds are on, but the connection > won't work. The Nokia box doesn't answer arp etc. If I now boot the Linux > machine, everything works again. This is a almost certainly a bug in the Nokia's repeater. The 3c905A uses an external MII transceiver, likely the DP83840. First, verify that you are not passing any options to the driver -- the driver should use the default MII mode. Run 'mii-diag -R' as root. This will reset the transceiver, which briefly brings the link down than then restarts autonegotiation/autosensing. > What might cause this? I'm guessing somekind of duplex negotiation > failure. Use 'mii-diag -w' to watch the link status as you unplug the cable. 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 From vherva@mail.niksula.cs.hut.fi Wed, 24 Jan 2001 17:51:48 +0200 Date: Wed, 24 Jan 2001 17:51:48 +0200 From: Ville Herva vherva@mail.niksula.cs.hut.fi Subject: [vortex] Problem with Nokia ADSL modem/hub and 3c905 On Wed, Jan 24, 2001 at 10:41:27AM -0500, you [Donald Becker] claimed: > On Wed, 24 Jan 2001, Ville Herva wrote: > > > I have a Nokia ADSL modem with 4 10MBit ethernet ports. I have a > > linux 2.2.18 box with one 3c905A connected to it. If I unplug the > > network cable from the Nokia box and try to plug it back, the link leds > > stay off. If If boot the Nokia box, the leds are on, but the connection > > won't work. The Nokia box doesn't answer arp etc. If I now boot the Linux > > machine, everything works again. > > This is a almost certainly a bug in the Nokia's repeater. That's what I figured, too. I was just interested in a way to circumvent it. > The 3c905A uses an external MII transceiver, likely the DP83840. > First, verify that you are not passing any options to the driver -- the > driver should use the default MII mode. I did try insmodding with or without options. I tried several times without options. > Run 'mii-diag -R' as root. This will reset the transceiver, which > briefly brings the link down than then restarts autonegotiation/autosensing. Will try when I get home. > > What might cause this? I'm guessing somekind of duplex negotiation > > failure. > > Use 'mii-diag -w' to watch the link status as you unplug the cable. Will do. thanks, -- v -- v@iki.fi From pp@ludusdesign.com Wed, 24 Jan 2001 11:48:48 -0500 Date: Wed, 24 Jan 2001 11:48:48 -0500 From: Pierre Phaneuf pp@ludusdesign.com Subject: [vortex] hardware TCP/IP checksum This is probably a FAQ, but it isn't in any FAQ that I can find. :-) Does the 3Com Vortex driver for Linux supports the TCP/IP checksumming using the card ASIC? I guess it doesn't, but I couldn't find anything to say it did or didn't. In either case, it would be nice to put a note on http://www.scyld.com/network/vortex.html to that effect. If it doesn't, is there a huge barrier to doing so? -- "The only 'intuitive' interface is the nipple. After that, it's all learned." -- bediger@teal.csn.org (on user interfaces) From vherva@mail.niksula.cs.hut.fi Wed, 24 Jan 2001 23:33:13 +0200 Date: Wed, 24 Jan 2001 23:33:13 +0200 From: Ville Herva vherva@mail.niksula.cs.hut.fi Subject: [vortex] Problem with Nokia ADSL modem/hub and 3c905 On Wed, Jan 24, 2001 at 08:51:04PM +1100, you [Andrew Morton] claimed: > > Could you please replace the existing 3c59x.c with the above file > and rebuild the driver. Then, force it to use the 10baseT > port with > > modprobe 3c59x options=0 > > and then test? Sorry for the flood. I think more too much debug info is better than too little, so please bear with me. With 'options=0' the connection (pinging Nokia box) does not work: insmod 3c59x options=0 debug=7 ========================================================================== 3c59x.c 16Aug00 Donald Becker and others http://www.scyld.com/network/vortex.html eth0: 3Com 3c905 Boomerang 100baseTx at 0xc400, 00:60:08:0b:99:9e, IRQ 19 Internal config register is 16302d8, transceivers 0xe040. 8K word-wide RAM 3:5 Rx:Tx split, autoselect/MII interface. Media override to transceiver type 0 (10baseT). Enabling bus-master transmits and whole-frame receives. eth0: Media override to transceiver 0 (10baseT). eth0: Initial media type 10baseT. eth0: vortex_open() InternalConfig 010302d8. eth0: vortex_open() irq 19 media status 8820. eth0: Filling in the Rx ring. bridge-eth0: found peer eth0 bridge-eth0: up eth0: Media selection timer tick happened, 10baseT. eth0: Media 10baseT has link beat, 88e0. eth0: Media selection timer finished, 10baseT. eth0: Trying to send a boomerang packet, Tx index 0. eth0: interrupt, status e201, latency 10, cur_rx 0, dirty_rx 0 eth0: In interrupt loop, status e201. eth0: exiting interrupt, status e000. eth0: Trying to send a boomerang packet, Tx index 1. eth0: interrupt, status e201, latency 8, cur_rx 0, dirty_rx 0 eth0: In interrupt loop, status e201. eth0: exiting interrupt, status e000. eth0: Trying to send a boomerang packet, Tx index 2. eth0: interrupt, status e201, latency 8, cur_rx 0, dirty_rx 0 eth0: In interrupt loop, status e201. eth0: exiting interrupt, status e000. eth0: Trying to send a boomerang packet, Tx index 3. eth0: interrupt, status e201, latency 10, cur_rx 0, dirty_rx 0 eth0: In interrupt loop, status e201. eth0: exiting interrupt, status e000. eth0: Trying to send a boomerang packet, Tx index 4. eth0: interrupt, status e201, latency 8, cur_rx 0, dirty_rx 0 eth0: In interrupt loop, status e201. eth0: exiting interrupt, status e000. eth0: Trying to send a boomerang packet, Tx index 5. eth0: interrupt, status e201, latency 8, cur_rx 0, dirty_rx 0 eth0: In interrupt loop, status e201. eth0: exiting interrupt, status e000. eth0: vortex_close() status e000, Tx status 00. eth0: vortex close stats: rx_nocopy 0 rx_copy 0 tx_queued 6 Rx pre-checksummed 0. bridge-eth0: lost peer eth0 bridge-eth0: down ========================================================================== Without 'options=0' it works: insmod 3c59x debug=7 ========================================================================== 3c59x.c 16Aug00 Donald Becker and others http://www.scyld.com/network/vortex.html eth0: 3Com 3c905 Boomerang 100baseTx at 0xc400, 00:60:08:0b:99:9e, IRQ 19 Internal config register is 16302d8, transceivers 0xe040. 8K word-wide RAM 3:5 Rx:Tx split, autoselect/MII interface. MII transceiver found at address 24, status 786d. Enabling bus-master transmits and whole-frame receives. eth0: Initial media type MII. eth0: MII #24 status 786d, link partner capability 0021, setting half-duplex. eth0: vortex_open() InternalConfig 016302d8. eth0: vortex_open() irq 19 media status 8802. eth0: Filling in the Rx ring. bridge-eth0: found peer eth0 bridge-eth0: up eth0: interrupt, status e401, latency 7, cur_rx 0, dirty_rx 0 eth0: In interrupt loop, status e401. In boomerang_rx(), status e001, rx_status 8000. Receiving packet size 98 status 8062. eth0: exiting interrupt, status e000. eth0: Trying to send a boomerang packet, Tx index 0. eth0: interrupt, status e201, latency 8, cur_rx 1, dirty_rx 1 eth0: In interrupt loop, status e201. eth0: In interrupt loop, status e401. In boomerang_rx(), status e001, rx_status 8000. Receiving packet size 60 status 803c. eth0: exiting interrupt, status e000. eth0: interrupt, status e401, latency 7, cur_rx 2, dirty_rx 2 eth0: In interrupt loop, status e401. In boomerang_rx(), status e001, rx_status 8000. Receiving packet size 60 status 803c. eth0: exiting interrupt, status e000. eth0: Trying to send a boomerang packet, Tx index 1. eth0: interrupt, status e201, latency 8, cur_rx 3, dirty_rx 3 eth0: In interrupt loop, status e201. eth0: exiting interrupt, status e000. eth0: Trying to send a boomerang packet, Tx index 2. eth0: interrupt, status e201, latency 11, cur_rx 3, dirty_rx 3 eth0: In interrupt loop, status e201. eth0: exiting interrupt, status e000. eth0: interrupt, status e401, latency 8, cur_rx 3, dirty_rx 3 eth0: In interrupt loop, status e401. In boomerang_rx(), status e001, rx_status 8000. Receiving packet size 98 status 8062. eth0: exiting interrupt, status e000. eth0: Media selection timer tick happened, MII. eth0: MII transceiver has status 786d. eth0: Media selection timer finished, MII. eth0: interrupt, status e401, latency 8, cur_rx 4, dirty_rx 4 eth0: In interrupt loop, status e401. In boomerang_rx(), status e001, rx_status 8000. Receiving packet size 98 status 8062. eth0: exiting interrupt, status e000. eth0: Trying to send a boomerang packet, Tx index 3. eth0: interrupt, status e201, latency 8, cur_rx 5, dirty_rx 5 eth0: In interrupt loop, status e201. eth0: exiting interrupt, status e000. ========================================================================== > If that doesn't work then could you please send a full report, along the > following lines: > > 1: load the driver with `modprobe 3c59x debug=7' > 2: ifup eth0 > 3: wait > one minute > 4: unplug the interface > 5: wait > one minute > 6: reattach the interface > 7: wait > 1 minute > > then send the logfiles along with the mii-diag and vortex-diag > output when the interface is good and when it's bad. Instructions > for this are at http://www.uow.edu.au/~andrewm/linux/vortex.txt > > If you can do all this, we'll get it fixed :) Now to the actual tests. These are with 'insmod 3c59x debug=7' and 2.2.18pre19 3c59x.c (I realize this the preferred version for neither Donald nor Andrew. I will redo with newer drivers the test if you want so.) 1) After insmod. Everything works. ========================================================================== root@babbage:/root/3c59x>mii-diag -v mii-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Using the default interface 'eth0'. MII PHY #24 transceiver registers: 3100 786d 2000 5c01 0141 0021 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 8060 8020 0c78 0000 3000 a3b9 0077 ca05 001b. Basic mode control register 0x3100: Auto-negotiation enabled. You have link beat, and everything is working OK. This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation complete. Your link partner is generating 10baseT link beat (no autonegotiation). MII PHY #24 transceiver registers: 3100 786d 2000 5c01 0141 0021 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 8060 8020 0c78 0000 3000 a3b9 0077 af05 001b. Basic mode control register 0x3100: Auto-negotiation enabled. Basic mode status register 0x786d ... 786d. Link status: established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation complete. Vendor ID is 08:00:17:--:--:--, model 0 rev. 1. Vendor/Part: National Semiconductor 83840A. I'm advertising 0141: 100baseTx-FD 10baseT-FD Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 0021: 10baseT. Negotiation did not complete. ========================================================================== ========================================================================== root@babbage:/root/3c59x>vortex-diag -eeaa vortex-diag.c:v2.04 1/8/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a 3c905 Boomerang 100baseTx adapter at 0xc400. The Vortex chip may be active, so FIFO registers will not be read. To see all register values use the '-f' flag. Initial window 7, registers values by window: Window 0: 0000 0000 0000 0000 0000 00bf ffff 0000. Window 1: FIFO FIFO 0000 2000 8000 00ff 13fc 2000. Window 2: 6000 0b08 9e99 0000 0000 0000 06c6 4000. Window 3: 02d8 0163 0000 0020 e040 0bff 13ff 6000. Window 4: 0000 06d0 0000 0cc0 0003 8802 0000 8000. Window 5: 1ffc fffc 06c6 0600 0007 06ce 06c6 a000. Window 6: 0000 0000 0000 0000 0000 0000 0000 c000. Window 7: aac8 0214 0000 0000 8000 00ff 500c e000. Vortex chip registers at 0xc400 0xC410: **FIFO** 00000000 00008000 *STATUS* 0xC420: 00000021 00000000 0f962242 06000024 0xC430: 00000000 00005313 0214a870 00000000 Indication enable is 06c6, interrupt enable is 06ce. No interrupt sources are pending. Transceiver/media interfaces available: MII. Transceiver type in use: MII. MAC settings: full-duplex. Maximum packet size is 0. Station address set to 00:60:08:0b:99:9e. Configuration options 06c6. EEPROM contents (64 words, offset 0): 0x000: 0060 080b 999e 9050 c321 0036 4b4b 6d50 0x008: 0418 0000 0060 080b 999e 8020 0000 0000 0x010: 10a6 0000 02d8 0163 0000 0000 0000 009b 0x018: ffff ffff ffff ffff ffff ffff ffff ffff 0x020: ffff ffff ffff ffff ffff ffff ffff ffff 0x028: ffff ffff ffff ffff ffff ffff ffff ffff 0x030: ffff ffff ffff ffff ffff ffff ffff ffff 0x038: ffff ffff ffff ffff ffff ffff ffff ffff The word-wide EEPROM checksum is 0xe9e0. Parsing the EEPROM of a 3Com Vortex/Boomerang: 3Com Node Address 00:60:08:0B:99:9E (used as a unique ID only). OEM Station address 00:60:08:0B:99:9E (used as the ethernet address). Manufacture date (MM/DD/YYYY) 9/1/1997, division 6, product KK. Options: force full-duplex. Vortex format checksum is correct (009b vs. 009b). Cyclone format checksum is incorrect (00 vs. 0xff). Hurricane format checksum is incorrect (00 vs. 0xff). ========================================================================== 2) Unplug and replug the cable. Wait a minute before and after replugging. the link leds stay off. ========================================================================== root@babbage:/root/3c59x>mii-diag -v mii-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Using the default interface 'eth0'. MII PHY #24 transceiver registers: 3100 7849 2000 5c01 0141 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 8060 8020 0c78 0000 3000 a3b9 0080 8005 001b. Basic mode control register 0x3100: Auto-negotiation enabled. Basic mode status register 0x7849 ... 7849. Link status: not established. This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation not complete. MII PHY #24 transceiver registers: 3100 7849 2000 5c01 0141 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 8060 8020 0c78 0000 3000 a3b9 0080 8005 001b. Basic mode control register 0x3100: Auto-negotiation enabled. Basic mode status register 0x7849 ... 7849. Link status: not established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation not complete. Vendor ID is 08:00:17:--:--:--, model 0 rev. 1. Vendor/Part: National Semiconductor 83840A. I'm advertising 0141: 100baseTx-FD 10baseT-FD Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 0000:. Negotiation did not complete. ========================================================================== ========================================================================== root@babbage:/root/3c59x>vortex-diag -eeaa vortex-diag.c:v2.04 1/8/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a 3c905 Boomerang 100baseTx adapter at 0xc400. The Vortex chip may be active, so FIFO registers will not be read. To see all register values use the '-f' flag. Initial window 7, registers values by window: Window 0: 0000 0000 0000 0000 0000 00bf ffff 0000. Window 1: FIFO FIFO 0000 2000 8000 00ff 13fc 2000. Window 2: 6000 0b08 9e99 0000 0000 0000 06c6 4000. Window 3: 02d8 0163 0000 0020 e040 0bff 13ff 6000. Window 4: 0000 06d0 0000 0cc0 0003 8802 0000 8000. Window 5: 1ffc fffc 06c6 0600 0007 06ce 06c6 a000. Window 6: 0000 0000 0000 0000 0000 0000 0000 c000. Window 7: aa08 0214 0000 0000 8000 00ff 500c e000. Vortex chip registers at 0xc400 0xC410: **FIFO** 00000000 00008000 *STATUS* 0xC420: 00000021 00000000 0f962242 06000024 0xC430: 00000000 000088a8 0214a8b0 00000000 Indication enable is 06c6, interrupt enable is 06ce. No interrupt sources are pending. Transceiver/media interfaces available: MII. Transceiver type in use: MII. MAC settings: full-duplex. Maximum packet size is 0. Station address set to 00:60:08:0b:99:9e. Configuration options 06c6. EEPROM contents (64 words, offset 0): 0x000: 0060 080b 999e 9050 c321 0036 4b4b 6d50 0x008: 0418 0000 0060 080b 999e 8020 0000 0000 0x010: 10a6 0000 02d8 0163 0000 0000 0000 009b 0x018: ffff ffff ffff ffff ffff ffff ffff ffff 0x020: ffff ffff ffff ffff ffff ffff ffff ffff 0x028: ffff ffff ffff ffff ffff ffff ffff ffff 0x030: ffff ffff ffff ffff ffff ffff ffff ffff 0x038: ffff ffff ffff ffff ffff ffff ffff ffff The word-wide EEPROM checksum is 0xe9e0. Parsing the EEPROM of a 3Com Vortex/Boomerang: 3Com Node Address 00:60:08:0B:99:9E (used as a unique ID only). OEM Station address 00:60:08:0B:99:9E (used as the ethernet address). Manufacture date (MM/DD/YYYY) 9/1/1997, division 6, product KK. Options: force full-duplex. Vortex format checksum is correct (009b vs. 009b). Cyclone format checksum is incorrect (00 vs. 0xff). Hurricane format checksum is incorrect (00 vs. 0xff). ========================================================================== 3) Now I did ========================================================================== root@babbage:/root/3c59x>ifconfig eth0 down root@babbage:/root/3c59x>mii-diag -rR Using the default interface 'eth0'. Resetting the transceiver... Restarting negotiation... Basic registers of MII PHY #24: 1200 7849 2000 5c01 01e1 0000 0000 0000. Basic mode control register 0x1200: Auto-negotiation enabled. Restarted auto-negotiation in progress! Basic mode status register 0x7849 ... 7849. Link status: not established. ========================================================================== After a while, the link leds are suddenly on again. And the weird thing is that after this I can unplug and replug the cables just fine. Before this the connection failure was 100% reproducible. -- v -- v@iki.fi From vherva@mail.niksula.cs.hut.fi Wed, 24 Jan 2001 23:40:41 +0200 Date: Wed, 24 Jan 2001 23:40:41 +0200 From: Ville Herva vherva@mail.niksula.cs.hut.fi Subject: [vortex] Problem with Nokia ADSL modem/hub and 3c905 On Wed, Jan 24, 2001 at 10:41:27AM -0500, you [Donald Becker] claimed: > > Run 'mii-diag -R' as root. This will reset the transceiver, which > briefly brings the link down than then restarts autonegotiation/autosensing. As said in the previous message, this works. It even causes the successive repluggings to work, ie. I only have to do it once, and then I can replug all I want. Weird. > > What might cause this? I'm guessing somekind of duplex negotiation > > failure. > 1 > Use 'mii-diag -w' to watch the link status as you unplug the cable. After mii-diag -rR (when replugging works okay): root@babbage:/root/3c59x>mii-diag -w Using the default interface 'eth0'. Basic registers of MII PHY #24: 1000 786d 2000 5c01 01e1 0021 0000 0000. Basic mode control register 0x1000: Auto-negotiation enabled. You have link beat, and everything is working OK. Your link partner is generating 10baseT link beat (no autonegotiation). 23:28:27.1073834 Baseline value of MII BMSR (basic mode status register) is 786d. 23:28:33.1073834 MII BMSR now 7849: no link, NWay busy, No Jabber (0021). 23:28:39.1073834 MII BMSR now 7869: no link, NWay done, No Jabber (0021). New link partner capability is 0021 0000: 10baseT. 23:28:39.1073834 MII BMSR now 786d: Good link, NWay done, No Jabber (0021). Even though the replug problem used to be 100% reproducible, after mii-diag -rR I can't reproduce it even after resetting the Nokia box. Do you think I should try harder (boot the linux box -- which is a server so I'm not all that keen to boot it all the time, but I can do it) to reproduce it? I mean, mii-diag -R is all I need, but if you think that you could fix/workaround the driver to handle this automatically, I'll be happy to help. Also, if you think your newest driver (either Don's or Andrew's that is), behaves better, I can try. -- v -- v@iki.fi From vherva@mail.niksula.cs.hut.fi Wed, 24 Jan 2001 23:56:20 +0200 Date: Wed, 24 Jan 2001 23:56:20 +0200 From: Ville Herva vherva@mail.niksula.cs.hut.fi Subject: [vortex] Problem with Nokia ADSL modem/hub and 3c905 On Wed, Jan 24, 2001 at 10:41:27AM -0500, you [Donald Becker] claimed: > > Use 'mii-diag -w' to watch the link status as you unplug the cable. Okay, after rmmod and insmod I was able to reproduce it again. Should have tried that right away, silly me. here it is: before mii-diag -R: root@babbage:/root/3c59x>mii-diag -R Using the default interface 'eth0'. Resetting the transceiver... Basic registers of MII PHY #24: 3100 7849 2000 5c01 01e1 0000 0000 0000. Basic mode control register 0x3100: Auto-negotiation enabled. Basic mode status register 0x7849 ... 7849. Link status: not established. (nothing happens after that) and after mii-diag -R: root@babbage:/root/3c59x>mii-diag -w Using the default interface 'eth0'. Basic registers of MII PHY #24: 3100 786d 2000 5c01 01e1 0021 0000 0000. Basic mode control register 0x3100: Auto-negotiation enabled. You have link beat, and everything is working OK. Your link partner is generating 10baseT link beat (no autonegotiation). 23:55:40.1073834 Baseline value of MII BMSR (basic mode status register) is 786d. 23:55:43.1073834 MII BMSR now 7849: no link, NWay busy, No Jabber (0021). 23:55:47.1073834 MII BMSR now 7869: no link, NWay done, No Jabber (0021). New link partner capability is 0021 0000: 10baseT. 23:55:47.1073834 MII BMSR now 786d: Good link, NWay done, No Jabber (0021). -- v -- v@iki.fi From vherva@mail.niksula.cs.hut.fi Thu, 25 Jan 2001 00:07:48 +0200 Date: Thu, 25 Jan 2001 00:07:48 +0200 From: Ville Herva vherva@mail.niksula.cs.hut.fi Subject: [vortex] Problem with Nokia ADSL modem/hub and 3c905 On Wed, Jan 24, 2001 at 08:51:04PM +1100, you [Andrew Morton] claimed: > > The driver at http://www.uow.edu.au/~andrewm/linux/3c59x.c-2.2.19-pre6-1.gz > has been changed so that when you force it to use a particular interface, > then it simply does what you said. I downloaded that driver. The results are pretty similar: with 'debug=7': 3c59x.c 19Oct00 Donald Becker and others http://www.scyld.com/network/vortex.html eth0: 3Com 3c905 Boomerang 100baseTx at 0xc400, 00:60:08:0b:99:9e, IRQ 19 Internal config register is 16302d8, transceivers 0xe040. 8K word-wide RAM 3:5 Rx:Tx split, autoselect/MII interface. MII transceiver found at address 24, status 786d. Enabling bus-master transmits and whole-frame receives. ping works. When I unplug the cable: eth0: interrupt, status e401, latency 8, cur_rx 317, dirty_rx 317 eth0: In interrupt loop, status e401. In boomerang_rx(), status e001, rx_status 8000. Receiving packet size 60 status 803c. eth0: exiting interrupt, status e000. eth0: vortex_close() status e000, Tx status 00. eth0: vortex close stats: rx_nocopy 137 rx_copy 181 tx_queued 264 Rx pre-checksummed 0. bridge-eth0: lost peer eth0 bridge-eth0: down Ping does not work. and with 'options=0 debug=7': eth0: 3Com 3c905 Boomerang 100baseTx at 0xc400, 00:60:08:0b:99:9e, IRQ 19 Internal config register is 16302d8, transceivers 0xe040. 8K word-wide RAM 3:5 Rx:Tx split, autoselect/MII interface. Media override to transceiver type 0 (10baseT). Enabling bus-master transmits and whole-frame receives. eth0: Media override to transceiver 0 (10baseT). eth0: Initial media type 10baseT. eth0: vortex_open() InternalConfig 010302d8. eth0: vortex_open() irq 19 media status 8820. eth0: Filling in the Rx ring. bridge-eth0: found peer eth0 bridge-eth0: up Ping does not work after insmod and ifconfig. With this driver, the mii-diag -w output when unplugging and replugging is identical to the 2.2.18pre19 one. -- v -- v@iki.fi From becker@scyld.com Wed, 24 Jan 2001 18:27:11 -0500 (EST) Date: Wed, 24 Jan 2001 18:27:11 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [vortex] hardware TCP/IP checksum On Wed, 24 Jan 2001, Pierre Phaneuf wrote: > Does the 3Com Vortex driver for Linux supports the TCP/IP checksumming > using the card ASIC? Old version of 3c59x.c do not, but the driver has supported it for several years. Keep in mind that the checksum hardware was only added with the 905B. 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 From becker@scyld.com Wed, 24 Jan 2001 18:33:30 -0500 (EST) Date: Wed, 24 Jan 2001 18:33:30 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [vortex] Problem with Nokia ADSL modem/hub and 3c905 On Thu, 25 Jan 2001, Ville Herva wrote: > with 'debug=7': ... > ping works. > > When I unplug the cable: > > eth0: interrupt, status e401, latency 8, cur_rx 317, dirty_rx 317 > eth0: In interrupt loop, status e401. > In boomerang_rx(), status e001, rx_status 8000. > Receiving packet size 60 status 803c. > eth0: exiting interrupt, status e000. > eth0: vortex_close() status e000, Tx status 00. > eth0: vortex close stats: rx_nocopy 137 rx_copy 181 tx_queued 264 Rx > pre-checksummed 0. > bridge-eth0: lost peer eth0 > bridge-eth0: down > > Ping does not work. Does the receiver stop? I note that you are doing bridging -- does problem exist without the bridge code? > and with 'options=0 debug=7': > eth0: 3Com 3c905 Boomerang 100baseTx at 0xc400, 00:60:08:0b:99:9e, IRQ 19 > Internal config register is 16302d8, transceivers 0xe040. > 8K word-wide RAM 3:5 Rx:Tx split, autoselect/MII interface. > Media override to transceiver type 0 (10baseT). This will definitely not work. The 3c905 has a MII transceiver, not a 10baseT transceiver. > Ping does not work after insmod and ifconfig. 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 From pp@ludusdesign.com Wed, 24 Jan 2001 19:52:05 -0500 Date: Wed, 24 Jan 2001 19:52:05 -0500 From: Pierre Phaneuf pp@ludusdesign.com Subject: [vortex] hardware TCP/IP checksum Donald Becker wrote: > > Does the 3Com Vortex driver for Linux supports the TCP/IP checksumming > > using the card ASIC? > > Old version of 3c59x.c do not, but the driver has supported it for several > years. Really? This means that the version in current Linux kernels (2.2 and onward) have it, or do I have to download a different line of drivers? > Keep in mind that the checksum hardware was only added with the 905B. I guess that if they brag about it on the box, it's in (I'm looking at the 3c920, which used to be something else I don't remember)... > 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 Hmm, competition! I work for HNSX Supercomputers... :-) -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/ From becker@scyld.com Wed, 24 Jan 2001 23:25:10 -0500 (EST) Date: Wed, 24 Jan 2001 23:25:10 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [vortex] hardware TCP/IP checksum On Wed, 24 Jan 2001, Pierre Phaneuf wrote: > Donald Becker wrote: > > > Does the 3Com Vortex driver for Linux supports the TCP/IP checksumming > > > using the card ASIC? > > > > Old version of 3c59x.c do not, but the driver has supported it for several > > years. > > Really? This means that the version in current Linux kernels (2.2 and > onward) have it, or do I have to download a different line of drivers? Yes, the current drivers have it. The central code looks like skb->protocol = eth_type_trans(skb, dev); { /* Use hardware checksum info. */ int csum_bits = rx_status & 0xee000000; if (csum_bits && (csum_bits == (IPChksumValid | TCPChksumValid) || csum_bits == (IPChksumValid | UDPChksumValid))) { skb->ip_summed = CHECKSUM_UNNECESSARY; rx_csumhits++; } } > > Second Generation Beowulf Clusters > > Hmm, competition! I work for HNSX Supercomputers... :-) Watch the supercomputing press releases next week, and let us know when NEC plans your cluster product. 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 From vherva@mail.niksula.cs.hut.fi Thu, 25 Jan 2001 08:33:52 +0200 Date: Thu, 25 Jan 2001 08:33:52 +0200 From: Ville Herva vherva@mail.niksula.cs.hut.fi Subject: [vortex] Problem with Nokia ADSL modem/hub and 3c905 On Wed, Jan 24, 2001 at 06:33:30PM -0500, you [Donald Becker] claimed: > > On Thu, 25 Jan 2001, Ville Herva wrote: > > > bridge-eth0: lost peer eth0 > > bridge-eth0: down > > Does the receiver stop? When unplugging the cable? How do I know that? From the debug=7 dmesg output? That should have been everything that got into logs, but I can recheck this night. > I note that you are doing bridging -- does problem exist without the > bridge code? Umh, those are propably from the vmware bridge module. The problem does appear without that module as well. > > and with 'options=0 debug=7': > > eth0: 3Com 3c905 Boomerang 100baseTx at 0xc400, 00:60:08:0b:99:9e, IRQ 19 > > Internal config register is 16302d8, transceivers 0xe040. > > 8K word-wide RAM 3:5 Rx:Tx split, autoselect/MII interface. > > Media override to transceiver type 0 (10baseT). > > This will definitely not work. The 3c905 has a MII transceiver, not a > 10baseT transceiver. I only did it because of Andrew's suggestion. Propably some misunderstanding. -- v -- v@iki.fi From mglan@wmdata.com Thu, 25 Jan 2001 10:00:46 +0100 Date: Thu, 25 Jan 2001 10:00:46 +0100 From: Larsson Magnus mglan@wmdata.com Subject: [vortex] networking problems Hi, I don't know if this is the right place to ask this question but ill give it a go anyway. I own a Compaq Armada e500 that has a 3com Megahertz 10/100 LAN CardBus NIC (PCMCIA). This card uses the 3c59x driver and i have compiled the driver into the kernel (2.4.0), i have also tried it as a module. My problem is that I get many errors, they are increasing all the time when i run ifconfig to check. And after a few minutes my network connection freezes wich means that I cant connect to anything and my current downloads 'stalls'. When this happens I have to reboot my computer to be able to download for another few minutes again. I have no idea what this is caused by so I'll include some entries from /var/log/syslog and /var/log/messages. Syslog: Jan 24 15:26:42 WMLI002676 kernel: eth0: transmit timed out, tx_status 00 status e000. Jan 24 15:26:42 WMLI002676 kernel: Flags; bus-master 1, full 1; dirty 1381(5) current 1397(5). Jan 24 15:26:42 WMLI002676 kernel: Transmit list 0030b250 vs. c030b250. Jan 24 15:26:42 WMLI002676 kernel: 0: @c030b200 length 8000002a status 0000002a Jan 24 15:26:42 WMLI002676 kernel: 1: @c030b210 length 8000002a status 0000002a Jan 24 15:26:42 WMLI002676 kernel: 2: @c030b220 length 8000002a status 0000002a Jan 24 15:26:42 WMLI002676 kernel: 3: @c030b230 length 8000002a status 8000002a Jan 24 15:26:42 WMLI002676 kernel: 4: @c030b240 length 8000004a status 8000004a Jan 24 15:26:42 WMLI002676 kernel: 5: @c030b250 length 80000036 status 00010036 Jan 24 15:26:42 WMLI002676 kernel: 6: @c030b260 length 80000036 status 00000036 Jan 24 15:26:42 WMLI002676 kernel: 7: @c030b270 length 80000036 status 00000036 Jan 24 15:26:42 WMLI002676 kernel: 8: @c030b280 length 80000036 status 00000036 Jan 24 15:26:42 WMLI002676 kernel: 9: @c030b290 length 80000036 status 00000036 Jan 24 15:26:42 WMLI002676 kernel: 10: @c030b2a0 length 80000036 status 00000036 Jan 24 15:26:42 WMLI002676 kernel: 11: @c030b2b0 length 80000036 status 00000036 Jan 24 15:26:42 WMLI002676 kernel: 12: @c030b2c0 length 8000004a status 0000004a Jan 24 15:26:42 WMLI002676 kernel: 13: @c030b2d0 length 8000002a status 0000002a Jan 24 15:26:42 WMLI002676 kernel: 14: @c030b2e0 length 8000004a status 0000004a Jan 24 15:26:42 WMLI002676 kernel: 15: @c030b2f0 length 8000002a status 0000002a Messages: Jan 24 15:20:33 WMLI002676 kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 24 15:21:04 WMLI002676 last message repeated 39 times Jan 24 15:22:05 WMLI002676 last message repeated 76 times Jan 24 15:23:06 WMLI002676 last message repeated 77 times Jan 24 15:24:07 WMLI002676 last message repeated 76 times Jan 24 15:25:08 WMLI002676 last message repeated 76 times Jan 24 15:26:09 WMLI002676 last message repeated 76 times Jan 24 15:26:31 WMLI002676 last message repeated 28 times I have also noticed a warning when I boot that says: "PCI: No IRQ known for interupt pin A of device 02:00.0. Please try using pci=biosirq" So, I tried to enter "linux pci=biosirq" at the liloprompt And then I only got the first part of the message: "PCI: No IRQ known for interupt pin A of device 02:00.0." Could this have something to do with it. Im a bit desperate so any suggestions are welcome! /magnus From andrewm@uow.edu.au Thu, 25 Jan 2001 23:21:02 +1100 Date: Thu, 25 Jan 2001 23:21:02 +1100 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] networking problems Larsson Magnus wrote: > > Hi, > > I don't know if this is the right place to ask this question but ill give it > a go anyway. It'll do. I'm a little surprised at this. Are you sure there is no `Tx error' message? Could you please send some more info? I suggest you add the line kern.* /var/log/kernel to /etc/syslog.conf and restart syslog, just to make sure we get everything. Then, please make sure you send all the relevant info from /var/log/kernel after the problem has occurred. You say that ifconfig shows errors, what are they? What sort of network is it? Hubbed 10baseT? Does the laptop work OK with other versions of the driver or kernel? > ... > > I have also noticed a warning when I boot that says: > > "PCI: No IRQ known for interupt pin A of device 02:00.0. Please try using > pci=biosirq" > > So, I tried to enter "linux pci=biosirq" at the liloprompt > > And then I only got the first part of the message: > "PCI: No IRQ known for interupt pin A of device 02:00.0." > > Could this have something to do with it. > That's quite common. I think it's because the BIOS doesn't describe to the OS the interrupt assignment of devices behind the cardbus bridge. But I haven't looked into it. From stikky@gameplay.com Mon, 29 Jan 2001 14:01:30 -0000 Date: Mon, 29 Jan 2001 14:01:30 -0000 From: Mark Ridley stikky@gameplay.com Subject: [vortex] RH7 and 3C905B Problems Hi, I am new to the list, but would appreciate some help with my current setup, apologies if this is in a FAQ, if it is, could you redirect me! :) Anyway, I have a box running RedHat 7 that has a 3C905B, that is connected, back-to-back with a Window 98 box. It seems that whenever I transfer large amounts of data, ifconfig reports frame errors, than the networking just grinds to a halt after say 2 minutes of activity. This is so annoying since it didn't used to happen in RedHat 6.2... any help much appreciated and will save the handfuls of hair that I have already pulled out! :) Cheers. -- Mark Ridley Gameplay From bogdan.costescu@iwr.uni-heidelberg.de Mon, 29 Jan 2001 16:05:57 +0100 (CET) Date: Mon, 29 Jan 2001 16:05:57 +0100 (CET) From: Bogdan Costescu bogdan.costescu@iwr.uni-heidelberg.de Subject: [vortex] RH7 and 3C905B Problems On Mon, 29 Jan 2001, Mark Ridley wrote: > Anyway, I have a box running RedHat 7 that has a 3C905B, that is connected, > back-to-back with a Window 98 box. It seems that whenever I transfer large > amounts of data, ifconfig reports frame errors, than the networking just > grinds to a halt after say 2 minutes of activity. > > This is so annoying since it didn't used to happen in RedHat 6.2... any help > much appreciated and will save the handfuls of hair that I have already > pulled out! :) AFAIK, both RH6.2 and RH7 provide two drivers for this card: the 3c59x driver originally written by Donald Becker and the 3c90x driver by 3Com. What driver are you using now and what driver did you use before ? You can also download vortex-diag and mii-diag from http://www.scyld.com/network/vortex.html to help understand what is going on. Finally: are there any error messages reported in the logs ? Sincerely, Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From stikky@gameplay.com Mon, 29 Jan 2001 17:48:08 -0000 Date: Mon, 29 Jan 2001 17:48:08 -0000 From: Mark Ridley stikky@gameplay.com Subject: [vortex] RH7 and 3C905B Problems > AFAIK, both RH6.2 and RH7 provide two drivers for this card: the 3c59x > driver originally written by Donald Becker and the 3c90x driver by 3Com. > What driver are you using now and what driver did you use before ? I compiled the one from 3Com with RH6.2, but it doesn't compile on RH7. :/ > You can also download vortex-diag and mii-diag from > http://www.scyld.com/network/vortex.html to help understand what is going > on. Okay thanks, done this. Not quite sure what it's telling me though! :) > Finally: are there any error messages reported in the logs ? No, this is the strange thing, the only report of an error I get is from ifconfig telling me there was either 1 or 2 frame errors then boom, it's all over... :) Many thanks. -- Mark Ridley Gameplay From bogdan.costescu@iwr.uni-heidelberg.de Mon, 29 Jan 2001 19:13:35 +0100 (CET) Date: Mon, 29 Jan 2001 19:13:35 +0100 (CET) From: Bogdan Costescu bogdan.costescu@iwr.uni-heidelberg.de Subject: [vortex] RH7 and 3C905B Problems On Mon, 29 Jan 2001, Mark Ridley wrote: > I compiled the one from 3Com with RH6.2, but it doesn't compile on RH7. :/ Try to use the 3c59x driver which comes with your distribution. For this, the /etc/conf.modules file should have in it: alias eth0 3c59x > Okay thanks, done this. Not quite sure what it's telling me though! :) First of all, starting from the previously mentioned page there are some diag links where you can see how these programs can be used. Then, you can also send us the output from the programs... Sincerely, Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From bwilson@tislabs.com Wed, 31 Jan 2001 04:06:16 -0800 (PST) Date: Wed, 31 Jan 2001 04:06:16 -0800 (PST) From: Brett M. Wilson bwilson@tislabs.com Subject: [vortex] Card: 3c509C Kernel: 2.4.1 Kernel message problem I'm not sure who's in charge of the 3c59x driver right now so I thought I'd just send this to the list. (I'm not a subscriber so please reply by email). The following lines were added to the driver as of 2.4.1 around line 1047. + step = (inb(ioaddr + Wn4_NetDiag) & 0x1e) >> 1; + printk(KERN_INFO " product code '%c%c' rev %02x.%d date %02d-" + "%02d-%02d\n", eeprom[6]&0xff, eeprom[6]>>8, eeprom[0x14], + step, (eeprom[4]>>5) & 15, eeprom[4] & 31, eeprom[4]>>9); The problems comes with the 2 product code characters. (eeprom[6]&0xff, eeprom[6]>>8). For my card (3c509C), the print from dmesg will be: ====================================================================== eth0: 3Com PCI 3c905C Tornado at 0xec80, 00:b0:d0:61:d9:29, IRQ 10 product code '' rev 00.14 date 07-16-104 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 782d. Enabling bus-master transmits and whole-frame receives. ====================================================================== The product code shows up as nothing (unprintable characters?). Now this doesn't bother me. (I'm not that anal retentive. :) However, something from this string is is really confusing klogd which upon getting to the product code line with enter an infinite loop in what appears to be strcpy. After startup I have to restart klogd to clear the problem and continue on. This problem is relieved when I remove the two %c%c and their arguments from the printk. I believe klogd should be able to deal with this situation without an infinite loop (strncpy) but I am assuming that the eeprom locations being read are not the correct ones. Brett FYI, this is a Debian 2.2 system with a 2.4 kernel. --------------------------------------------------------- Brett M. Wilson Adaptive Network Defense Group NAI Labs, Glenwood, MD (443) 259-2300 Remote Office: Federal Way, WA (253) 835-6157