Date: Mon, 27 May 1996 02:44:15 +0300 (EET DST) From: Heikki Suonsivu <hsu@clinet.fi> To: FreeBSD-gnats-submit@freebsd.org Subject: kern/1256: ZNYX 314 mysterously looses packets Message-ID: <199605262344.CAA25883@cantina.clinet.fi> Resent-Message-ID: <199605262350.QAA13825@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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<FPU,VME,DE,PSE,TSC,MSR,MC 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 <generic PCI bridge (vendor=1039 dev ice=5511 subclass=0)> rev 0 on pci0:0 May 26 06:52:58 otaniemi6-gw /kernel: chip1 <SiS 85c503> 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 <DEC 21050 PCI-PCI bridge> rev 2 on pci0:9 May 26 06:52:58 otaniemi6-gw /kernel: chip3 <DEC 21050 PCI-PCI bridge> rev 2 on pci0:10 May 26 06:52:58 otaniemi6-gw /kernel: chip4 <DEC 21050 PCI-PCI bridge> rev 1 on pci0:11 May 26 06:52:58 otaniemi6-gw /kernel: chip5 <DEC 21050 PCI-PCI bridge> 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 <Digital DC21040 Ethernet> 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 <Digital DC21040 Ethernet> 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 <Digital DC21040 Ethernet> 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 <Digital DC21040 Ethernet> 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 <Digital DC21040 Ethernet> 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 <Digital DC21040 Ethernet> 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 <Digital DC21040 Ethernet> 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 <Digital DC21040 Ethernet> 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 <Digital DC21040 Ethernet> 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 <Digital DC21040 Ethernet> 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 <Link> 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 <Link> 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 <Link> 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 <Link> 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 <Link> 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 <Link> 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:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605262344.CAA25883>