From owner-freebsd-bugs Sun May 26 19:52:13 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA20390 for bugs-outgoing; Sun, 26 May 1996 19:52:13 -0700 (PDT) Received: from sasami.jurai.net (root@sasami.jurai.net [206.151.208.162]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA20222; Sun, 26 May 1996 19:51:49 -0700 (PDT) Received: from localhost (winter@localhost) by sasami.jurai.net (8.7.5/8.7.3) with SMTP id VAA29971; Sun, 26 May 1996 21:52:10 -0500 (CDT) Date: Sun, 26 May 1996 21:52:09 -0500 (CDT) From: "Matthew N. Dodd" X-Sender: winter@sasami To: Heikki Suonsivu cc: FreeBSD-gnats-submit@freebsd.org, GNATS Management , freebsd-bugs@freefall.freebsd.org Subject: Re: kern/1256: ZNYX 314 mysterously looses packets In-Reply-To: <199605262344.CAA25883@cantina.clinet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm running 2 314s with no problem using the new dc21040 drivers, and a patch to pcisupport.c. You should probably be able to get these changes from Matt Thomas. I've had this code running on the new and the old rev of the ZX314. Its been in production for a week and a half now working flawlessly. On Mon, 27 May 1996, Heikki Suonsivu wrote: > >Number: 1256 > >Category: kern > >Synopsis: ZNYX 314 mysterously looses packets > >Confidential: no > >Severity: serious > >Priority: high > >Responsible: freebsd-bugs > >State: open > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Sun May 26 16:50:00 PDT 1996 > >Last-Modified: > >Originator: Heikki Suonsivu > >Organization: > Clinet, Espoo, Finland > >Release: FreeBSD 2.2-CURRENT i386 > >Environment: > > May 26 03:52:55 otaniemi6-gw /kernel: CPU: Pentium (89.81-MHz 586-class CPU) > May 26 03:52:56 otaniemi6-gw /kernel: Origin = "GenuineIntel" Id = 0x525 Ste > pping=5 > May 26 03:52:56 otaniemi6-gw /kernel: Features=0x1bf E,CX8> > May 26 03:52:56 otaniemi6-gw /kernel: real memory = 16777216 (16384K bytes) > May 26 03:52:56 otaniemi6-gw /kernel: avail memory = 14471168 (14132K bytes) > May 26 03:52:56 otaniemi6-gw /kernel: Probing for devices on PCI bus 0: > May 26 03:52:56 otaniemi6-gw /kernel: chip0 ice=5511 subclass=0)> rev 0 on pci0:0 > May 26 06:52:58 otaniemi6-gw /kernel: chip1 rev 1 on pci0:1:0 > May 26 06:52:58 otaniemi6-gw /kernel: pci0:1:1: Silicon Integrated Systems, devi > ce=0x5513, class=storage (ide) int a irq ?? [no driver assigned] > May 26 06:52:58 otaniemi6-gw /kernel: chip2 rev 2 on > pci0:9 > May 26 06:52:58 otaniemi6-gw /kernel: chip3 rev 2 on > pci0:10 > May 26 06:52:58 otaniemi6-gw /kernel: chip4 rev 1 on > pci0:11 > May 26 06:52:58 otaniemi6-gw /kernel: chip5 rev 2 on > pci0:12 > May 26 06:52:58 otaniemi6-gw /kernel: Probing for devices on PCI bus 1: > May 26 06:52:58 otaniemi6-gw /kernel: de0 rev 35 int > a irq 9 on pci1:4 > May 26 06:52:58 otaniemi6-gw /kernel: de0: DC21040 [10Mb/s] pass 2.3 Ethernet ad > dress 00:00:c0:01:0b:c0 > May 26 06:52:58 otaniemi6-gw /kernel: de0: enabling Thinwire/AUI port > May 26 06:52:58 otaniemi6-gw /kernel: de1 rev 35 int > a irq 11 on pci1:5 > May 26 06:52:58 otaniemi6-gw /kernel: de1: DC21040 [10Mb/s] pass 2.3 Ethernet ad > dress 00:00:c0:e0:09:c0 > May 26 06:52:58 otaniemi6-gw /kernel: de1: enabling Thinwire/AUI port > May 26 06:52:58 otaniemi6-gw /kernel: Probing for devices on PCI bus 2: > May 26 06:52:58 otaniemi6-gw /kernel: de2 rev 35 int > a irq 12 on pci2:4 > May 26 06:52:58 otaniemi6-gw /kernel: de2: DC21040 [10Mb/s] pass 2.3 Ethernet ad > dress 00:00:c0:50:01:c0 > May 26 06:52:58 otaniemi6-gw /kernel: de2: enabling Thinwire/AUI port > May 26 06:52:58 otaniemi6-gw /kernel: de3 rev 35 int > a irq 9 on pci2:5 > May 26 06:52:58 otaniemi6-gw /kernel: de3: DC21040 [10Mb/s] pass 2.3 Ethernet ad > dress 00:00:c0:1e:02:c0 > May 26 06:52:58 otaniemi6-gw /kernel: de3: enabling Thinwire/AUI port > May 26 06:52:59 otaniemi6-gw /kernel: Probing for devices on PCI bus 3: > May 26 06:52:59 otaniemi6-gw /kernel: de4 rev 35 int > a irq 10 on pci3:4 > May 26 06:52:59 otaniemi6-gw /kernel: pcibus_ihandler_attach: counting pci irq10 > 's as clk0 irqs > May 26 06:52:59 otaniemi6-gw /kernel: de4: ZNYX ZX314 DC21040 [10Mb/s] pass 2.3 > Ethernet address 00:c0:95:f0:05:3c > May 26 06:52:59 otaniemi6-gw /kernel: de4: enabling 10baseT/UTP port > May 26 06:52:59 otaniemi6-gw /kernel: de5 rev 35 int > a irq 12 on pci3:5 > May 26 06:52:59 otaniemi6-gw /kernel: de5: ZNYX ZX314 DC21040 [10Mb/s] pass 2.3 > Ethernet address 00:c0:95:f0:05:3d > May 26 06:52:59 otaniemi6-gw /kernel: de5: enabling 10baseT/UTP port > May 26 06:52:59 otaniemi6-gw /kernel: de6 rev 35 int > a irq 9 on pci3:6 > May 26 06:52:59 otaniemi6-gw /kernel: de6: ZNYX ZX314 DC21040 [10Mb/s] pass 2.3 > Ethernet address 00:c0:95:f0:05:3e > May 26 06:52:59 otaniemi6-gw /kernel: de6: enabling 10baseT/UTP port > May 26 06:52:59 otaniemi6-gw /kernel: de7 rev 35 int > a irq 11 on pci3:7 > May 26 06:52:59 otaniemi6-gw /kernel: de7: ZNYX ZX314 DC21040 [10Mb/s] pass 2.3 > Ethernet address 00:c0:95:f0:05:3f > May 26 06:52:59 otaniemi6-gw /kernel: de7: enabling 10baseT/UTP port > May 26 06:52:59 otaniemi6-gw /kernel: Probing for devices on PCI bus 4: > May 26 06:52:59 otaniemi6-gw /kernel: de8 rev 35 int > a irq 11 on pci4:4 > May 26 06:52:59 otaniemi6-gw /kernel: de8: DC21040 [10Mb/s] pass 2.3 Ethernet ad > dress 00:00:c0:3a:0b:c0 > May 26 06:53:00 otaniemi6-gw /kernel: de8: enabling Thinwire/AUI port > May 26 06:53:00 otaniemi6-gw /kernel: de9 rev 35 int > a irq 10 on pci4:5 > May 26 06:53:00 otaniemi6-gw /kernel: pcibus_ihandler_attach: counting pci irq10 > 's as clk0 irqs > May 26 06:53:00 otaniemi6-gw /kernel: de9: DC21040 [10Mb/s] pass 2.3 Ethernet ad > dress 00:00:c0:bb:08:c0 > May 26 06:53:00 otaniemi6-gw /kernel: de9: enabling Thinwire/AUI port > May 26 06:53:00 otaniemi6-gw /kernel: Probing for devices on the ISA bus: > > > >Description: > > ZNYX 314 ports seem to transmit/receive packets but they are "lost". > For example, traceroute packets and telnet connection startup work, > but ping packets or telnet connection data packets are lost. I also > see other odd effects like one machine repeatably failing to receive > file larger than 100k (first it goes well, then it stops receiving and > after a minute or so it says "connection reset by peer"). This only > happens with ZNYX 314, not with, say SMC Etherpower^2. The problem > depends on port being used, one port may work, the other does not. > > ee1-gw# netstat -I de8 > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll > de8 1500 00.c0.95.f0.00.ff 268 0 109 0 0 > de8 1500 194.100.0.220 ee1-gw 268 0 109 0 0 > ee1-gw# > > otaniemi3-gw# netstat -I de7 > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll > de7 1500 00.c0.95.f0.01.4f 140 0 288 0 0 > de7 1500 194.100.0.220 otaniemi3-gw 140 0 288 0 0 > otaniemi3-gw# > > ee1-gw# ping 194.100.0.221 > PING 194.100.0.221 (194.100.0.221): 56 data bytes > ^C > --- 194.100.0.221 ping statistics --- > 4 packets transmitted, 0 packets received, 100% packet loss > ee1-gw# > > ee1-gw# netstat -I de8 > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll > de8 1500 00.c0.95.f0.00.ff 268 0 109 0 0 > de8 1500 194.100.0.220 ee1-gw 268 0 109 0 0 > ee1-gw# > > otaniemi3-gw# netstat -I de7 > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll > de7 1500 00.c0.95.f0.01.4f 144 0 288 0 0 > de7 1500 194.100.0.220 otaniemi3-gw 144 0 288 0 0 > otaniemi3-gw# > > otaniemi3-gw sees packets coming from ee1-gw, but does not reply them. > If I try traceroute instead: > > ee1-gw# netstat -I de8 > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll > de8 1500 00.c0.95.f0.00.ff 269 0 113 0 0 > de8 1500 194.100.0.220 ee1-gw 269 0 113 0 0 > ee1-gw# traceroute 194.100.0.221 > traceroute to 194.100.0.221 (194.100.0.221), 30 hops max, 40 byte packets > 1 otaniemi3-gw.espoo.clinet.fi (194.100.0.221) 0.897 ms 0.621 ms 0.586 ms > ee1-gw# netstat -I de8 > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll > de8 1500 00.c0.95.f0.00.ff 272 0 116 0 0 > de8 1500 194.100.0.220 ee1-gw 272 0 116 0 0 > ee1-gw# > > So traceroute works normally. > > >How-To-Repeat: > > I can repeat this every time. > > >Fix: > > Kernel should provide more diagnostics. If the packets are somehow > corrupted, kernel should complain about it. Now the packets seem to > be silently discarded. Could this be a PCI problem ? I do have one > configuration which is working correctly, and two configurations > which do not. > > >Audit-Trail: > >Unformatted: > | Matthew N. Dodd | winter@jurai.net | http://www.jurai.net/~winter | | Technical Manager | mdodd@intersurf.net | http://www.intersurf.net | | InterSurf Online | "Welcome to the net Sir, would you like a handbasket?"|