Re: Stalls on sync PPP transmission (new card)

Henner Eisen (eis@baty.hanse.de)
Sat, 16 Oct 1999 00:32:28 +0200


>>>>> "Ivan" == Ivan Passos <ivan@mediacity.com> writes:
>>
>> Leave it out. tbusy should only be set in the
>> dev->hard_start_xmit() thread when an xmitter-busy condition is
>> detected (in your driver, this is probably at those location
>> where your cpc_queue_xmit() returns 1). Other threads
>> (e.g. interrupt handlers) are only allowed to clear tbusy.

Ivan> This is _not_ the interrupt handler, this is the function to
Ivan> which
>dev-> hard_start_xmit() points to. Furthermore, isn't the

Yes, I was aware of this.

>dev-> test_and_set_bit
This particular atomic bitop was used before linux 1.2.9 to serialize
dev->hard_start_xmit() calls internally. This is no longer necessary because
since linux 1.2.9, the network layer takes care that for each net device,
dev->hard_start_xmit is called in a single threaded manner.

Ivan> _BUT_ for this device, as it has _large_ DMA buffers (you
Ivan> can queue up to 32KB of TX data per channel), the driver
Ivan> doesn't need to wait until the board has actually physically
Ivan> placed the data in the line to tell the upper layer that
Ivan> it's ready to receive more data. Once the data from the
Ivan> upper layer is in the DMA buffer, the driver is ready to
Ivan> receive more data from the upper layer. That's why tbusy is
Ivan> _set_ and _cleared_ in the same function (cpc_queue_xmit,
Ivan> which is dev->hard_start_xmit).

But the linux network layer will easily fill up the whole 32KB DMA buffer,
if this is full, your device´s hard_start_xmit will return with tbusy set,
and after that the network layer will cease to call dev->hard_start_xmit().
With tbusy set, the hardware will send out the frames in the DMA buffer,
makeing space for new frames, but as tbusy remains set, the upper layer
won´t call dev->hard_start_xmit() again. (well, after some time it will
although tbusy is set, this is exactly to trigger the xmit timeout
recovery in your xmit function).

BTW, even if your hardware can queue 32kB, it might be better for
performance to limit the length ob the internal buffer. It is better
to let the upper layer take care of queuing because the upper layer
can be more intelligent (fair queueung, prioritizing,...).

Henner

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/