RE: Problems with Intel e100 driver on new MIPS port, was: Advice needed WRT very slow nfs in new port...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Title: Re: Problems with Intel e100 driver on new MIPS port, was: Advice needed WRT very slow nfs in new port...
David Daney wrote:
>Michael Stickel wrote:
>> M. Warner Losh wrote:
>>
>>> In message: <42C359F8.4060000@xxxxxxxxxx>
>>>            David Daney <ddaney@xxxxxxxxxx> writes:
>>> : M. Warner Losh wrote:
>>> : > In message: <42C34C4D.9020902@xxxxxxxxxx>
>>> : >             David Daney <ddaney@xxxxxxxxxx> writes:
>>> : > : Does anyone have any idea what would cause 1000mS delay?
>>> : > : > That's remarkably close to 1s.  This often indicates that the
>>> transmit
>>> : > of your next packet is causing the receive buffer to empty.  This is
>>> : > usually due to blocked interrupts, or a failure to enable interrupts.
>>> : > : : But I observe ever increasing counts for the device in
>>> /proc/interrupts. :   So the interrupts are working somewhat.
>>>
>>> Are you sure that you've routed the interrupts correctly?  Maybe those
>>> interrupts are 'really' for a different device....
>>> 
>>>
>> Add some debugging to the interrupt routine of the e100 and see what
>> happens.
>
>The interrupt routine is getting called each time a packet is received.
>
>It looks like packets are not being transmitted until the interrupt for
>the the received packet is received.
>
>If I ping the board at different intervals the round trip time is always
>almost exactly equal to the ping interval.  So if I ping every 50mS the
>round trip time is 50mS, ping every 200mS gives a RTT of 200mS, etc.
>
>Any more ideas?
>
>I am thinking that perhaps the CPU write-back-queue is interfearing with
>writes to the NIC's registers.  Perhaps I will try to disable it.
I think I solved the problem.

It seems that it is a memory consistancy problem of some sort.  By placing wbflush() after all writes to NIC registers it works.  This leads me to think that either the driver is buggy WRT processors that have write-back queues or my implementation (the default implementation) of writeb() and friends is buggy on this processor.  Now it could be that all that is needed is wmb() before some of the register writes, but since on my processor they both do the same thing (sync) it is hard to tell.

That will be the subject of my next message.

David Daney



[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux