Re: Via-Rhine Driver - questions for D. Becker.

["Ivan G." <ivangurdiev@linuxfreemail.com>]

> The earlier versions of the driver produced that messsage for most
> unusual events.  The problem was that normal events combined with
> uncommon events would trigger the message.  The driver at scyld.com
> cleaned up the check for events that trigger the message long ago.

Yes, I saw that problem. How do you define
"unusual events". Right now your "Wicked" trap will catch
IntrTxUnderrun, IntrPCIErr, and any other interrupts not in
IntrNormalSummary that occur along MIIChange,StatsMax,LinkChange,
Underrun, Abort, or PCIErr, and issue a CmdTxDemand on each.
Was this the intention?


> There is a race condition when adding a new descriptor to the Tx
> descriptor list.  The driver might add the descriptor just a cycle too
> late, leaving the just-queued packet untransmitted.  It's safe to make
> extra calls to CmdTxDemand, so the driver does this after every packet
> is queued.

This is interesting. The reason why I started messing with the driver in
the first place was because my card was stalling. Some investigation
showed that 1 Tx Done interrupt clears 2 descriptor ownership bits
after which the card stalls. hmm.

> RxNoBuf doesn't apply.  In our case it will always occur in conjunction
> with IntrRxEmpty, which is the event we handle.

Okay, but you use it to call netdev_rx while you haven't included it
when setting the interrupt mask. The kernel driver does the same.
The same is true for IntrTxAbort and IntrRxWakeUp.
Also, why are there two interrupts that do the same thing according
to documentation (aborted and abort).

> See the datasheet.
> We handle it implicitly by refilling the Rx descriptors.

The kernel driver includes it in the interrupt mask
and never uses it explicitly. Should it be removed?

----------------------------------------------
Some additional interrupt questions:
IntrMIIChange is defined as Transmit Descriptor Underflow by the docs (??)
IntrRxDropped is defined as FIFO Overflow (??)