From owner-linux-ns83820@kvack.org Sun Mar 7 17:52:47 2004 Received: (root@kanga.kvack.org) by kvack.org id ; Sun, 7 Mar 2004 17:52:38 -0500 Received: from sccrmhc11.comcast.net ([204.127.202.55]:40587 "EHLO sccrmhc11.comcast.net") by kvack.org with ESMTP id ; Sun, 7 Mar 2004 17:52:29 -0500 Received: from eklhad (pcp02692649pcs.roylok01.mi.comcast.net[68.84.176.25]) by comcast.net (sccrmhc11) with SMTP id <2004030722521801100hkbgqe>; Sun, 7 Mar 2004 22:52:18 +0000 To: linux-ns83820@kvack.org From: Karl Dahlke Reply-to: Karl Dahlke Subject: "tx after" error messages, thousands of them Date: Sun, 07 Mar 2004 17:54:27 Message-ID: <20040207175427.eklhad@comcast.net> Mime-Version: 1.0 Content-type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-ns83820@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org Return-Path: X-Envelope-To: <"|/home/majordomo/wrapper archive -f /home/ftp/pub/archives/linux-ns83820/linux-ns83820 -m -a"> (uid 0) X-Orcpt: rfc822;linux-ns83820-outgoing Original-Recipient: rfc822;linux-ns83820-outgoing They look like this. eth1: after: tx_done_idx=89 free_idx=103 cmdsts=8000002a And I get a couple of them every second. I reinstalled the module with reset_phy=1 and they stoppped coming. But I don't know why they started, and if they will come again. Any ideas? Oh, I am on kernel 2.6.3, and here is the version info. eth1: ns83820 v0.20: DP83820 v1.2: 00:04:e2:1a:d5:79 io=0xf7024000 irq=11 f=sg eth1: link now 100 mbps, half duplex and up. I don't normally subscribe to this list, so please respond to eklhad@comcast.net Thanks, Karl -- To unsubscribe, send a message with 'unsubscribe linux-ns83820' in the body to majordomo@kvack.org. From owner-linux-ns83820@kvack.org Sun Mar 14 18:07:52 2004 Received: (root@kanga.kvack.org) by kvack.org id ; Sun, 14 Mar 2004 18:07:42 -0500 Received: from ghoul.undead.cc ([216.126.84.18]:13185 "HELO mail.undead.cc") by kvack.org with SMTP id ; Sun, 14 Mar 2004 18:07:37 -0500 Received: (qmail 748 invoked from network); 14 Mar 2004 23:03:22 -0000 Received: from vampire.undead.cc (HELO undead.cc) (216.126.84.19) by mail.undead.cc with SMTP; 14 Mar 2004 23:03:22 -0000 Message-ID: <4054E598.9080203@undead.cc> Date: Sun, 14 Mar 2004 18:07:04 -0500 From: John Zielinski User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-ns83820@kvack.org Subject: Re: Bug in version .20 of ns83820 driver References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------010901090605050403000709" Sender: owner-linux-ns83820@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org Return-Path: X-Envelope-To: <"|/home/majordomo/wrapper archive -f /home/ftp/pub/archives/linux-ns83820/linux-ns83820 -m -a"> (uid 0) X-Orcpt: rfc822;linux-ns83820-outgoing Original-Recipient: rfc822;linux-ns83820-outgoing This is a multi-part message in MIME format. --------------010901090605050403000709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Here's a patch that I did to the driver which lets me bring the interface down and back up without problems. I'm not a Linux networking expert so I've probably missed something. Please let me know of any improvements. John --------------010901090605050403000709 Content-Type: text/plain; name="down_fix.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="down_fix.patch" diff -u linux.old/drivers/net/ns83820.c linux/drivers/net/ns83820.c --- linux/drivers/net/ns83820.c.orig 2004-02-17 22:59:44.000000000 -0500 +++ linux/drivers/net/ns83820.c 2004-03-14 17:17:33.000000000 -0500 @@ -793,7 +793,7 @@ /* touch the pci bus... */ readl(dev->base + IMR); - /* assumes the transmitter is already disabled and reset */ + /* assumes the receiver is already disabled and reset */ writel(0, dev->base + RXDP_HI); writel(0, dev->base + RXDP); @@ -1007,22 +1007,43 @@ static void ns83820_cleanup_tx(struct ns83820 *dev) { - unsigned i; + u32 tx_done_idx; - for (i=0; itx_skbs[i]; - dev->tx_skbs[i] = NULL; + dprintk("ns83820_cleanup_tx(%p)\n", dev); + + /* disable receive interrupts */ + spin_lock_irq(&dev->misc_lock); + dev->IMR_cache &= ~(ISR_TXURN | ISR_TXIDLE | ISR_TXERR | ISR_TXDESC | ISR_TXOK); + writel(0, dev->base + IMR); + spin_unlock_irq(&dev->misc_lock); + + /* assumes the transmitter is already disabled and reset */ + writel(0, dev->base + TXDP_HI); + writel(0, dev->base + TXDP); + + for (tx_done_idx = dev->tx_done_idx; tx_done_idx != dev->tx_free_idx; tx_done_idx = (tx_done_idx + 1) % NR_TX_DESC) { + u32 *desc = dev->tx_descs + (tx_done_idx * DESC_SIZE); + unsigned len = le32_to_cpu(desc[DESC_CMDSTS]) & CMDSTS_LEN_MASK; + dma_addr_t addr = desc_addr_get(desc + DESC_BUFPTR); + struct sk_buff *skb = dev->tx_skbs[tx_done_idx]; + dev->tx_skbs[tx_done_idx] = NULL; if (skb) { - u32 *desc = dev->tx_descs + (i * DESC_SIZE); pci_unmap_single(dev->pci_dev, - desc_addr_get(desc + DESC_BUFPTR), - le32_to_cpu(desc[DESC_CMDSTS]) & CMDSTS_LEN_MASK, + addr, + len, PCI_DMA_TODEVICE); dev_kfree_skb_irq(skb); atomic_dec(&dev->nr_tx_skbs); - } + } else + pci_unmap_page(dev->pci_dev, + addr, + len, + PCI_DMA_TODEVICE); } + dev->tx_done_idx = 0; + dev->tx_free_idx = 0; + memset(dev->tx_descs, 0, NR_TX_DESC * DESC_SIZE * 4); } @@ -1390,24 +1411,20 @@ del_timer_sync(&dev->tx_watchdog); /* disable interrupts */ - writel(0, dev->base + IMR); writel(0, dev->base + IER); - readl(dev->base + IER); - - dev->rx_info.up = 0; - synchronize_irq(dev->pci_dev->irq); - ns83820_do_reset(dev, CR_RST); - - synchronize_irq(dev->pci_dev->irq); - - spin_lock_irq(&dev->misc_lock); - dev->IMR_cache &= ~(ISR_TXURN | ISR_TXIDLE | ISR_TXERR | ISR_TXDESC | ISR_TXOK); - spin_unlock_irq(&dev->misc_lock); + /* shut down transmitter and receiver */ + writel(CR_TXD | CR_RXD, dev->base + CR); + do { + schedule(); + } while (readl(dev->base + CR) & (CR_TXE | CR_RXE)); ns83820_cleanup_rx(dev); ns83820_cleanup_tx(dev); + /* clear out left over ISR conditions */ + readl(dev->base + ISR); + return 0; } --------------010901090605050403000709-- -- To unsubscribe, send a message with 'unsubscribe linux-ns83820' in the body to majordomo@kvack.org. From owner-linux-ns83820@kvack.org Tue Mar 30 00:11:57 2004 Received: (root@kanga.kvack.org) by kvack.org id ; Tue, 30 Mar 2004 00:11:47 -0500 Received: from imf19aec.mail.bellsouth.net ([205.152.59.67]:18564 "EHLO imf19aec.mail.bellsouth.net") by kvack.org with ESMTP id ; Tue, 30 Mar 2004 00:11:35 -0500 Received: from nebula.internal.foo ([68.220.136.193]) by imf19aec.mail.bellsouth.net (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with ESMTP id <20040330051125.OFUF1775.imf19aec.mail.bellsouth.net@nebula.internal.foo>; Tue, 30 Mar 2004 00:11:25 -0500 Received: from faith.internal.foo ([192.168.0.12]) by nebula.internal.foo with esmtp (Exim 3.36 #1 (Debian)) id 1B8BX2-0000bR-00; Tue, 30 Mar 2004 00:11:24 -0500 From: Jason Boxman Reply-To: jasonb@edseek.com Organization: The Vortex To: linux-ns83820@kvack.org Subject: Re: Bug in version .20 of ns83820 driver Date: Tue, 30 Mar 2004 00:11:24 -0500 User-Agent: KMail/1.6.1 Cc: grim@undead.cc MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200403300011.24517.jasonb@edseek.com> Sender: owner-linux-ns83820@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org John: Return-Path: X-Envelope-To: <"|/home/majordomo/wrapper archive -f /home/ftp/pub/archives/linux-ns83820/linux-ns83820 -m -a"> (uid 0) X-Orcpt: rfc822;linux-ns83820-outgoing Original-Recipient: rfc822;linux-ns83820-outgoing Dude you rock! Your patch resolved my issue. I have both a Linksys EG1032 and a D-Link DGE-500T, both based on the ns83820 chipset. Both cards had the same issue in multiple machines under 2.4.22, 2.4.24, and 2.6.4. I applied your patch to 2.6.3 and the DGE-500T is able to obtain an IP address via DHCP or have one staticly assigned and ping other hosts. Before, either method resulted in errors. It looks like I won't have to get rid of these after all. If someone could get this patch merged into the next stable release of the kernel, that would be great. I can't imagine this situation is uncommon. (Although there is surprisingly little in Google about this.) If there are any tests or additional output I can provide, let me know. Thanks again! kernel: eth1: after: tx_done_idx=3 free_idx=4 cmdsts=8000002a kernel: eth1: after: tx_done_idx=3 free_idx=4 cmdsts=8000002a kernel: eth1: after: tx_done_idx=3 free_idx=4 cmdsts=8000002a kernel: eth1: after: tx_done_idx=3 free_idx=4 cmdsts=8000002a kernel: eth1: after: tx_done_idx=3 free_idx=4 cmdsts=8000002a kernel: eth1: after: tx_done_idx=3 free_idx=4 cmdsts=8000002a kernel: eth1: after: tx_done_idx=3 free_idx=4 cmdsts=8000002a kernel: eth1: after: tx_done_idx=3 free_idx=4 cmdsts=8000002a kernel: eth1: after: tx_done_idx=3 free_idx=4 cmdsts=8000002a kernel: eth1: after: tx_done_idx=3 free_idx=4 cmdsts=8000002a kernel: eth1: after: tx_done_idx=3 free_idx=4 cmdsts=8000002a kernel: eth1: after: tx_done_idx=3 free_idx=4 cmdsts=8000002a kernel: eth1: after: tx_done_idx=3 free_idx=4 cmdsts=8000002a kernel: eth1: after: tx_done_idx=3 free_idx=4 cmdsts=8000002a kernel: eth1: after: tx_done_idx=3 free_idx=4 cmdsts=8000002a kernel: eth1: after: tx_done_idx=3 free_idx=4 cmdsts=8000002a kernel: eth1: after: tx_done_idx=3 free_idx=4 cmdsts=8000002a kernel: eth1: after: tx_done_idx=3 free_idx=4 cmdsts=8000002a kernel: eth1: after: tx_done_idx=3 free_idx=4 cmdsts=8000002a kernel: eth1: after: tx_done_idx=3 free_idx=4 cmdsts=8000002a kernel: eth1: after: tx_done_idx=3 free_idx=4 cmdsts=8000002a -- Jason Boxman Perl Programmer / *NIX Systems Administrator Shimberg Center for Affordable Housing | University of Florida http://edseek.com/ - Linux and FOSS stuff -- To unsubscribe, send a message with 'unsubscribe linux-ns83820' in the body to majordomo@kvack.org. From owner-linux-ns83820@kvack.org Tue Mar 30 22:13:49 2004 Received: (root@kanga.kvack.org) by kvack.org id ; Tue, 30 Mar 2004 22:13:39 -0500 Received: from mail.undead.cc ([216.126.84.18]:13440 "HELO mail.undead.cc") by kvack.org with SMTP id ; Tue, 30 Mar 2004 22:13:24 -0500 Received: (qmail 7814 invoked from network); 31 Mar 2004 03:08:59 -0000 Received: from vampire.undead.cc (HELO undead.cc) (216.126.84.19) by mail.undead.cc with SMTP; 31 Mar 2004 03:08:59 -0000 Message-ID: <406A3749.4050203@undead.cc> Date: Tue, 30 Mar 2004 22:13:13 -0500 From: John Zielinski User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jasonb@edseek.com CC: linux-ns83820@kvack.org Subject: Re: Bug in version .20 of ns83820 driver References: <200403300011.24517.jasonb@edseek.com> In-Reply-To: <200403300011.24517.jasonb@edseek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-ns83820@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org Return-Path: X-Envelope-To: <"|/home/majordomo/wrapper archive -f /home/ftp/pub/archives/linux-ns83820/linux-ns83820 -m -a"> (uid 0) X-Orcpt: rfc822;linux-ns83820-outgoing Original-Recipient: rfc822;linux-ns83820-outgoing Jason Boxman wrote: >Dude you rock! > >Your patch resolved my issue. > >I have both a Linksys EG1032 and a D-Link DGE-500T, both based on the ns83820 >chipset. Both cards had the same issue in multiple machines under 2.4.22, > > Great to hear! Hopefully the patch will be merged into the kernel soon. They'll probably want it tested a little more so if anyone else is using it successfully, please post a short message here. I found a pair of SMC9452TX cards in the local computer store for not too much so I grabbed them for a direct link between two of the machines. The 'down' problem got a little annoying while I was experimenting with them so I downloaded the data sheet and started tweaking. They're not bad but I wish they had a bigger transmit buffer than 8K. I tried running them with a 9000 MTU but the transmitter would always hang. Drove me nuts because the spec sheet indicated it could do it. Then I realized that the card can't do hardware checksum generation if the complete packet is not in the buffer. :( So it's either > 8192 MTU or hardware checksum. Since no hardware checksuming disables scather gather (zero copy) for the card in the kernel I've settled for a 6000 MTU which has been working quite well. John -- To unsubscribe, send a message with 'unsubscribe linux-ns83820' in the body to majordomo@kvack.org.