Date: Thu, 18 Jan 2001 23:35:33 -0500 From: Mike Tancsa <mike@sentex.net> To: Richard Hodges <rh@matriplex.com> Cc: freebsd-atm@freebsd.org Subject: Re: HARP (lockups) with hea Message-ID: <4.2.2.20010118205333.01e8dcd8@marble.sentex.net> In-Reply-To: <Pine.BSF.4.10.10101181707270.2085-100000@mail.matriplex.co m> References: <4.2.2.20010118194243.0387b7e8@marble.sentex.net>
next in thread | previous in thread | raw e-mail | index | archive | help
At 05:13 PM 1/18/2001 -0800, Richard Hodges wrote: >On Thu, 18 Jan 2001, Mike Tancsa wrote: > > > OK, I ran the same tests using the Chuck Cranor driver and the tests > > completed as expected. Any ideas how I would go debugging this ? > >You could compile the driver with "DO_LOG" and see if anything interesting >shows up in the system log. Sounds good. I will try that. Another thing I noticed was that doing ping -q -s 8000 -f <other side> on the HARP stack, gives me a max of 20Mb/s. Using the en, I get close to 90Mb/s. Quite a difference in throughput. >I don't see any obvious problem with private data vs. mbuf header >(like in the Fore driver), but I still wonder if it is possible >that this driver also needs to be updated. Is this problem associated >with receiving data? Are you getting UDP checksum errors? >("netstat -p udp") Hmm. I didnt check that, but a quick retest of it now shows with the en (after the netperf test and the big long ping flood) hespler2# ping -q -f -s 8000 192.168.1.2 PING 192.168.1.2 (192.168.1.2): 8000 data bytes ^C --- 192.168.1.2 ping statistics --- 4409936 packets transmitted, 4409561 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.305/5.083/7.002/0.409 ms and netstat -s looks just fine. Also, doing the same tests with one machine using HARP and the other using the en driver, they also complete without any errors. going from HARP to en0, also work. Jan 18 22:08:11 ruby2 /kernel: eni_output: not enough room in buffer Jan 18 22:08:11 ruby2 last message repeated 501 times Jan 18 22:08:11 ruby2 /kernel: Jan 18 22:08:11 ruby2 /kernel: eni_output: not enough room in buffer Jan 18 22:08:11 ruby2 /kernel: Jan 18 22:08:11 ruby2 /kernel: eni_output: not enough room in buffer Jan 18 22:08:11 ruby2 /kernel: eni_output: not enough room in buffer Jan 18 22:08:11 ruby2 last message repeated 112 times Jan 18 22:08:11 ruby2 /kernel: Jan 18 22:08:11 ruby2 last message repeated 23 times Jan 18 22:08:11 ruby2 /kernel: Jan 18 22:08:11 ruby2 /kernel: eni_output: not enoug>Jan 18 22:08:11 ruby2 /kernel: eni_outputm in bu ffer Jan 18 22:08:11 ruby2 /kernel: eni_output: not enough room in buffer Jan 18 22:08:11 ruby2 last message repeated 60 times Jan 18 22:08:11 ruby2 /kernel: Jan 18 22:08:11 ruby2 /kernel: eni_output: not enough room in buffer Jan 18 22:08:11 ruby2 /kernel: Jan 18 22:08:11 ruby2 last message repeated 22 times Jan 18 22:08:11 ruby2 /kernel: Jan 18 22:08:11 ruby2 /kernel: room in buffer Jan 18 22:08:11 ruby2 /kernel: Jan 18 22:08:11 ruby2 last message repeated 22 times Jan 18 22:08:11 ruby2 /kernel: Jan 18 22:08:11 ruby2 /kernel: room in buffer Jan 18 22:08:11 ruby2 /kernel: Jan 18 22:08:11 ruby2 /kernel: eni_output: not enough room in buffer Jan 18 22:08:11 ruby2 /kernel: Jan 18 22:08:11 ruby2 /kernel: eni_output: not enough room in buffer ruby2# netstat -p udp udp: 1652231 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 24 dropped due to no socket 0 broadcast/multicast datagrams dropped due to no socket 0 dropped due to full socket buffers 0 not for hashed pcb 1652207 delivered 13057700 datagrams output Doesnt really show too much. But kern.* is full of Jan 18 22:29:10 ruby2 last message repeated 23 times Jan 18 22:29:10 ruby2 /kernel: eni_outt: not enough room in buffer Jan 18 22:29:10 ruby2 /kernel: eni_output: not enough room in buffer Jan 18 22:29:10 ruby2 last message repeated 23 times Jan 18 22:29:10 ruby2 /kernel: t: not enough room in buffer Jan 18 22:29:10 ruby2 /kernel: eni_output: not enough room in buffer Jan 18 22:29:10 ruby2 last message repeated 23 times Jan 18 22:29:10 ruby2 /kernel: eni_outt: not enough room in buffer Jan 18 22:29:10 ruby2 /kernel: eni_output: not enough room in buffer Jan 18 22:29:10 ruby2 last message repeated 23 times Jan 18 22:29:10 ruby2 /kernel: t: not enough room in buffer Jan 18 22:29:10 ruby2 /kernel: eni_output: not enough room in buffer Jan 18 22:29:10 ruby2 last message repeated 23 times Jan 18 22:29:10 ruby2 /kernel: eni_outt: not enough room in buffer Jan 18 22:29:10 ruby2 /kernel: eni_output: not enough room in buffer Jan 18 22:29:10 ruby2 last message repeated 797 times Jan 18 22:32:35 ruby2 /kernel: eni_output: not enough room in buffer There is nothing on the other end of the test, even with debugging enabled. ruby2# atm show stats vcc Input Input Input Output Output Output Interface VPI VCI PDUs Bytes Errs PDUs Bytes Errs hea0 0 130 3675302 161664468 0 4421957 -94882376 0 Is there any other way to reset the adaptor short of a reboot ? I tried delete the pvc on both ends, downing the interface, but nothing short of a reboot seems to work. Syslog shows atm0: not multicast capable, IPv6 not enabled eni_output: not enough room in buffer eni_output: not enough room in buffer atm0: not multicast capable, IPv6 not enabled eni_output: not enough room in buffer eni_output: not enough room in buffer eni_output: not enough room in buffer Reading through the archives, Chuck Cranor pointed out that - the HARP driver does not test the DMA engine at boot time to verify proper operation. - the HARP driver does not dynamically determine what DMA burst sizes are valid on a specific system and does not handle the strict DMA alignment required on some systems (e.g. the "alburst" restriction common on sparcs). Instead the HARP driver hardwares the max DMA burst to 8 words and doesn't make use of 16 word DMA bursts. I guess I will need to stick with the en driver for now. Thanks for any suggestions and tips! ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Network Administration, mike@sentex.net Sentex Communications www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-atm" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.2.2.20010118205333.01e8dcd8>