From hsu@clinet.fi  Sun May 26 16:44:28 1996
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA12440
          for <FreeBSD-gnats-submit@freebsd.org>; Sun, 26 May 1996 16:44:26 -0700 (PDT)
Received: from cantina.clinet.fi (root@cantina.clinet.fi [194.100.0.15]) by hauki.clinet.fi (8.7.5/8.6.4) with ESMTP id CAA06743 for <FreeBSD-gnats-submit@freebsd.org>; Mon, 27 May 1996 02:44:16 +0300 (EET DST)
Received: (hsu@localhost) by cantina.clinet.fi (8.7.5/8.6.4) id CAA25883; Mon, 27 May 1996 02:44:15 +0300 (EET DST)
Message-Id: <199605262344.CAA25883@cantina.clinet.fi>
Date: Mon, 27 May 1996 02:44:15 +0300 (EET DST)
From: Heikki Suonsivu <hsu@clinet.fi>
Reply-To: hsu@clinet.fi
To: FreeBSD-gnats-submit@freebsd.org
Subject: ZNYX 314 mysterously looses packets
X-Send-Pr-Version: 3.2

>Number:         1256
>Category:       kern
>Synopsis:       ZNYX 314 mysterously looses packets
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun May 26 16:50:00 PDT 1996
>Closed-Date:    Sat Feb 5 05:29:18 PST 2000
>Last-Modified:  Sat Feb  5 05:29:37 PST 2000
>Originator:     Heikki Suonsivu
>Release:        FreeBSD 2.2-CURRENT i386
>Organization:
Clinet, Espoo, Finland
>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.

>Release-Note:
>Audit-Trail:

From: "Matthew N. Dodd" <winter@jurai.net>
To: Heikki Suonsivu <hsu@clinet.fi>
Cc: FreeBSD-gnats-submit@freebsd.org,
        GNATS Management <gnats@freefall.freebsd.org>,
        freebsd-bugs@freefall.freebsd.org
Subject: Re: kern/1256: ZNYX 314 mysterously looses packets
Date: Sun, 26 May 1996 21:52:09 -0500 (CDT)

 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<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:
 > 
 
 | 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?"|
 

From: asami@cs.berkeley.edu (Satoshi Asami)
To: freebsd-gnats-submit@freefall.freebsd.org
Cc:  Subject: Re: kern/1256: ZNYX 314 mysterously looses packets
Date: Sun, 26 May 1996 22:31:22 -0700 (PDT)

  *  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.
 
 I've heard about this patch from many people, is there a reason why it 
 can't go into -current?
 
 Satoshi
State-Changed-From-To: open->feedback 
State-Changed-By: scrappy 
State-Changed-When: Mon Oct 21 22:24:10 PDT 1996 
State-Changed-Why:  

confirm status 

State-Changed-From-To: feedback->open 
State-Changed-By: scrappy 
State-Changed-When: Tue Oct 22 22:50:39 PDT 1996 
State-Changed-Why:  

From: Heikki Suonsivu <hsu@clinet.fi> 

This is still open.  It may be card dependent, as I have one card still in 
production use and three which won't work at all.  I haven't tried lately 
but I do not think I have seen any patches for this. 


From: Heikki Suonsivu <hsu@clinet.fi>
To: freebsd-gnats-submit@freebsd.org
Cc: hsu@clinet.fi
Subject: kern/1256 ZNYX 314 mysterously looses packets
Date: Sat, 28 Mar 1998 04:34:30 +0200 (EET)

 I would like to keep this around until we have tested the cards better
 again.  Ask me again in three months.
 
 Studded@dal.net writes:
  > Greetings, :)
  > 
  > 	I am writing to you in regards to your FreeBSD Problem
  > Report. The FreeBSD project is currently conducting a beta test on
  > version 2.2.6 and feedback as to whether you are still experiencing
  > your problem would be very valuable. 
  > 
  > 	If you are still experiencing the problem you reported, it
  > would help the project track the problem if you could upgrade to the
  > latest snapshot of 2.2.6-Beta (located at releng22.freebsd.org) and
  > test your problem again. 
  > 
  > 	If you have any feedback regarding this Problem Report,
  > whether you are still experiencing the problem or whether the PR can
  > be closed, please mail your response to
  > freebsd-gnats-submit@freebsd.org. Please do not respond directly to
  > me. I am merely a humble volunteer and have no official connection to
  > the FreeBSD project. Therefore I cannot make any changes to the status
  > of your Problem Report. It is also very important that you include 
  > the category and number of your Problem Report (kern/1256)
  > in the subject line of your response.
  > 
  > 	Another option if you need a refresher on the details of your
  > problem or would like to submit a followup is to use the web page
  > interface and look up your PR by number.
  > http://www.freebsd.org/cgi/query-pr-summary.cgi
  > 
  > 	Thank you for helping to make this the greatest release of
  > FreeBSD ever.
  > 
  > Doug
  > 
  > 
  > -- 
  > ***         Chief Operations Officer, DALnet IRC network       ***
  > *** Proud operator, designer and maintainer of the world's largest
  > *** Internet Relay Chat server.  5,328 clients and still growing.
  > *** Try spider.dal.net on ports 6662-4    (Powered by FreeBSD)
  > 
State-Changed-From-To: open->feedback 
State-Changed-By: phk 
State-Changed-When: Mon Apr 13 02:03:26 PDT 1998 
State-Changed-Why:  
so we'll see about this in june, right ? 

From: Sheldon Hearn <sheldonh@uunet.co.za>
To: hsu@clinet.fi
Cc: FreeBSD-gnats-submit@freebsd.org, asami@freebsd.org
Subject: Re: kern/1256: ZNYX 314 mysterously looses packets 
Date: Tue, 22 Jun 1999 16:05:48 +0200

 What's the status on the problem you were having with ZNYX 314 cards
 mysteriously losing packets? Did you ever try the patch to which Matthew
 Dodd made reference?
 
 The last we heard from you, you asked that you be contacted in 3 months.
 That was over a year ago. Sorry about the delay. ;-)
 
 Ciao,
 Sheldon.
 
State-Changed-From-To: feedback->closed 
State-Changed-By: asmodai 
State-Changed-When: Sat Feb 5 05:29:18 PST 2000 
State-Changed-Why:  
Originator feedback time-out. 
>Unformatted:
