Re: Ring buffer overflow and LAN91C111 ethernet driver

On Mar 25, 12:02 am, sant...@xxxxxxxxx wrote:
Hi Forum,

Thanks for your hardwork.

I am working on vxworks 5.5.1, tornado 2.2.1 and CPU SH5571.
And my network driver is SMSC LAN91C111 ethernet controller.

Err.... no. Your network _controller_ is the SMSC LAN91C111. Your
network driver is.... unknown. It could be one that Wind River ships,
or it could be one you wrote yourself. You should tell us.

Actully i am checking my target system that how it responds
when ring buffer overflow error is occured.

In order to generate ring buffer overflow, i reduced the size of
the size of the ring buffer from 85 to 40. And then i pinged 60000
bytes
of data to my target vxworks system.

From the above condition, i can able to generate ring buffer overflow
error message. And below are observations of the behaviour of my
target system,

1. All the network task running in my target system is delayed.(FTP,
PING...)
2. tNettask shows PEND state(but do not suspends)
3. ping shows request timed out.

And in my terminal, i use to get around 85(85 only is the main
problem) ring buffer
overflow messege like below

"0xd2b704c (tNetTask): panic: netJobAdd: ring buffer overflow!"

As stated above, ring buffer overflow message generates approximatly
around 85 times,
and stops generating.

In order to know why error message stopped, i checked the source code,
and below are
the observations,

1. i use to get error in driver receive routine.(Because
netClusterGet() function
in driver receive routine returns NULL).

2. RX_ABORT bit in RCR register is set.

3. Recieve interrupt continues to occur which inturn calls driver
receive routine continously.

From the above observation, i understood that data is not coming to
the driver,
though receive function is called as receive interrupt generated.
(I mean receive interrupt do not stops, but data is dropped in the
chip level)

Hence to confirm the above, i refferd the data*** of SMSC driver.
But there was no sufficent
information regarding the flow of rejecting the receving data.

Can anybody please tell me what exactly the process occur in hardware
in general or specific to SMSC driver.
(i.e data handling in hardware or DMA etc in general or specific to
the SMSC driver)

Or else if i am entirely wrong with my observation, if you had come
across this situation,
please tell me why the ring buffer overflow message stops after
sometime.

Thanks in Advance

A ring buffer overrun error like this usually indicates that the
driver is not guarding its calls to netJobAdd() correctly.

Note: the ring being overflowed here is the internal netJob ring used
by netJobAdd() and tNetTask. It's created using rngLib. It has
nothing to do with any DMA descriptor rings. In fact, the SMSC 91C111
is not a DMA-based device. I think it defaults to 50 entries.

For any given piece of work that the driver needs to do in tNetTask,
it should only execute one instance of netJobAdd(). For example, if
the chip receives a burst of 10 ethernet frames, you only need to do a
netJobAdd() once, on the first RX interrupt that occurs. At that
point, the driver should mask off the interrupt and set a flag to
indicate that the driver's RX handler routine has been scheduled to
run in tNetTask. Allowing subsequent interrupts to occur and calling
netJobAdd() again and again is pointless: the RX handler should scoop
out however many frames are waiting in the chip and only when the
receiver has been fully drained should it turn the RX interrupt back
on and allow the ISR to call netJobAdd() again.

Repeatedly calling netJobAdd() too frequently is a) unnecessary,
because it only takes one call to netJobAdd() to wake up tNetTask, and
b) can eventually consume all of the entries in the netJob ring and
subsequent calls to netJobAdd() to fail.

The SMSC 91C111 chip is very simple and does not implement DMA: it's a
programmed I/O device only. It also has a very small register space,
and the driver must use register bank switching in some cases. If I
remember right, it has a total of 8K of internal SRAM, which can be
divided up among the receiver and transmitter. However, since the CPU
must copy received frames directly out of the SRAM using 16-bit
register accesses only, it is very easy to overrun the receiver when
operating in 100Mbps mode: the CPU simply can't drain the RX memory
fast enough to keep up with the incoming traffic. At 10Mbps, it seems
to work ok though. All of this makes using the chip a little tricky.

Anyway, a properly written driver should _never_ generate a netJob
ring buffer overflow. If you write your driver as conservatively as as
possible, you can get your code to use only one netJobAdd() (in the
ISR) to dispatch a task level handler to deal with all events. At
worst, you might have one for RX events, one for TX events and one for
errors. In no case should you ever have more than one job outstanding
for any given event. So for example, in the latter case, you should
never have more than at most 3 netJobs pending. That is, you should
never schedule a second RX netJob until you know the first one has
completed, and never schedule a second TX netJob until the first is
completed, and so on. If you stick to this scheme, you will never
overflow the ring (unless you add many ethernet ports to your system,
because then each one will need 3 netJobs -- at this point, you may
need to make the ring larger).

-Bill
.

Loading