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>