Ethernet driver problem

Ethernet driver problem

[Nathan G. Grennan]

I got this last night on my 3cSOHO100-TX Hurricane card using the 3c59x
driver while running 2.4.15pre6. I was download a whole directory of
rpms, about 50 of them. I got this on dmesg. I ended up with 2 corrupted
files from the download. Never had this problem before. If it matters I
was using gftp 2.0.9pre3-1 and I was my non-root user.

eth0: Transmit error, Tx status register 82.
Probably a duplex mismatch.  See Documentation/networking/vortex.txt
  Flags; bus-master 1, dirty 337158(6) current 337158(6)
  Transmit list 00000000 vs. eee9d380.
  0: @eee9d200  length 80000252 status 00010252
  1: @eee9d240  length 80000036 status 00010036
  2: @eee9d280  length 80000042 status 00010042
  3: @eee9d2c0  length 80000036 status 00010036
  4: @eee9d300  length 80000263 status 00010263
  5: @eee9d340  length 80000036 status 80010036
  6: @eee9d380  length 80000042 status 00010042
  7: @eee9d3c0  length 80000036 status 00010036
  8: @eee9d400  length 80000244 status 00010244
  9: @eee9d440  length 80000036 status 00010036
  10: @eee9d480  length 80000042 status 00010042
  11: @eee9d4c0  length 80000036 status 00010036
  12: @eee9d500  length 80000244 status 00010244
  13: @eee9d540  length 80000036 status 00010036
  14: @eee9d580  length 80000042 status 00010042
  15: @eee9d5c0  length 80000036 status 00010036
eth0: Transmit error, Tx status register 82.
Probably a duplex mismatch.  See Documentation/networking/vortex.txt
  Flags; bus-master 1, dirty 346818(2) current 346818(2)
  Transmit list 00000000 vs. eee9d280.
  0: @eee9d200  length 80000251 status 00010251
  1: @eee9d240  length 80000036 status 80010036
  2: @eee9d280  length 80000042 status 00010042
  3: @eee9d2c0  length 80000036 status 00010036
  4: @eee9d300  length 80000273 status 00010273
  5: @eee9d340  length 80000036 status 00010036
  6: @eee9d380  length 80000042 status 00010042
  7: @eee9d3c0  length 80000042 status 00010042
  8: @eee9d400  length 80000042 status 00010042
  9: @eee9d440  length 80000042 status 00010042
  10: @eee9d480  length 80000036 status 00010036
  11: @eee9d4c0  length 80000251 status 00010251
  12: @eee9d500  length 80000036 status 00010036
  13: @eee9d540  length 8000004a status 0001004a
  14: @eee9d580  length 80000042 status 00010042
  15: @eee9d5c0  length 80000036 status 00010036
eth0: Transmit error, Tx status register 82.
Probably a duplex mismatch.  See Documentation/networking/vortex.txt
  Flags; bus-master 1, dirty 346819(3) current 346819(3)
  Transmit list 00000000 vs. eee9d2c0.
  0: @eee9d200  length 80000251 status 00010251
  1: @eee9d240  length 80000036 status 00010036
  2: @eee9d280  length 80000251 status 80010251
  3: @eee9d2c0  length 80000036 status 00010036
  4: @eee9d300  length 80000273 status 00010273
  5: @eee9d340  length 80000036 status 00010036
  6: @eee9d380  length 80000042 status 00010042
  7: @eee9d3c0  length 80000042 status 00010042
  8: @eee9d400  length 80000042 status 00010042
  9: @eee9d440  length 80000042 status 00010042
  10: @eee9d480  length 80000036 status 00010036
  11: @eee9d4c0  length 80000251 status 00010251
  12: @eee9d500  length 80000036 status 00010036
  13: @eee9d540  length 8000004a status 0001004a
  14: @eee9d580  length 80000042 status 00010042
  15: @eee9d5c0  length 80000036 status 00010036
eth0: Transmit error, Tx status register 82.
Probably a duplex mismatch.  See Documentation/networking/vortex.txt
  Flags; bus-master 1, dirty 346823(7) current 346823(7)
  Transmit list 00000000 vs. eee9d3c0.
  0: @eee9d200  length 80000251 status 00010251
  1: @eee9d240  length 80000036 status 00010036
  2: @eee9d280  length 80000251 status 00010251
  3: @eee9d2c0  length 80000042 status 00010042
  4: @eee9d300  length 80000042 status 00010042
  5: @eee9d340  length 8000004a status 0001004a
  6: @eee9d380  length 80000251 status 80010251
  7: @eee9d3c0  length 80000042 status 00010042
  8: @eee9d400  length 80000042 status 00010042
  9: @eee9d440  length 80000042 status 00010042
  10: @eee9d480  length 80000036 status 00010036
  11: @eee9d4c0  length 80000251 status 00010251
  12: @eee9d500  length 80000036 status 00010036
  13: @eee9d540  length 8000004a status 0001004a
  14: @eee9d580  length 80000042 status 00010042
  15: @eee9d5c0  length 80000036 status 00010036

Ethernet driver problem

[Jupe]

Hi,

I have written an ethernet driver for an ARM based board.
Linux version: 2.6.20.1

Ping is working fine.

I have written a test server/client application using socket programming
(TCP).
After the connection is setup the server sends a file to the client.

When I run server on PC and client on ARM board it works without any
problem.

BUT if I run server on ARM board and client on PC, it works for some
time and 
then the speed is drastically reduced. (I am sending 4k of data each
time.
after 50 sends it reduces its speed.  This happens always.)

I did some debugging and found that after 50 sends, tcp_sendmsg() is not
being 
called at the same frequency before slowdown.  Also when my driver
ether_tx seems to 
be working fine.

But still i am not able to get the reason for this behaviour.  Can
anyone give hints as to 
why this is happening? 


Regards
Jupe

-- 
  Jupe
  jupejupe@rushpost.com

-- 
http://www.fastmail.fm - mmm... Fastmail...

Re: Ethernet driver problem

[linux-os (Dick Johnson)]

On Wed, 10 Oct 2007, Jupe wrote:

> Hi,
>
> I have written an ethernet driver for an ARM based board.
> Linux version: 2.6.20.1
>
> Ping is working fine.
>
> I have written a test server/client application using socket programming
> (TCP).
> After the connection is setup the server sends a file to the client.
>
> When I run server on PC and client on ARM board it works without any
> problem.
>
> BUT if I run server on ARM board and client on PC, it works for some
> time and
> then the speed is drastically reduced. (I am sending 4k of data each
> time.
> after 50 sends it reduces its speed.  This happens always.)
>
> I did some debugging and found that after 50 sends, tcp_sendmsg() is not
> being
> called at the same frequency before slowdown.  Also when my driver
> ether_tx seems to
> be working fine.
>
> But still i am not able to get the reason for this behaviour.  Can
> anyone give hints as to
> why this is happening?
>
>
> Regards
> Jupe
>
> -- 
>  Jupe
>  jupejupe@rushpost.com
>
> -- 
> http://www.fastmail.fm - mmm... Fastmail...

First, does your TCP/IP test application work okay on
a Linux machine that does not use your new driver?

That's the first thing to test.

Next, is auto-negotiation working correctly in your
driver? If you don't have auto-negotiation, have you
set the Ethernet parameters correctly so that BOTH
the server and the client use either full-duplex, or
half-duplex, without mixing them up?

Next, make sure that you are properly handling
transmit retries (handling all possible errors)
in your driver. The transmitter does not want
to drop packets if there is no room in the
device, only the receiver should drop packets
if there are no buffers. You do not want
the TCP/IP replacement algorithm to request
missing packets because this slows everything
down. Again, in the transmitter section
of your driver, consider data precious.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips).
My book : http://www.AbominableFirebug.com/
_


****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: Ethernet driver problem

[Jupe]

Thanks for the reply

I have tested my program on PC and it works without any problem.

I have enabled auto negotiation.  The status register shows successful
completion of auto-negotiation.
And it shows using full duplex.

I did check whether the packets are getting dropped because of lack of
space.  But it is not the case.  I even created huge number of transmit
descriptors enough to fit 1.5 MBytes of data.  But still it slows down
after about 200 KB.  I even have used the setsockopt option available in
user program.  Nothing seems to increase the speed.

Any pointers on this would be greatly helpful

Thanking you
Jupe



On Wed, 10 Oct 2007 11:49:58 -0400, "linux-os (Dick Johnson)"
<linux-os@analogic.com> said:
> 
> On Wed, 10 Oct 2007, Jupe wrote:
> 
> > Hi,
> >
> > I have written an ethernet driver for an ARM based board.
> > Linux version: 2.6.20.1
> >
> > Ping is working fine.
> >
> > I have written a test server/client application using socket programming
> > (TCP).
> > After the connection is setup the server sends a file to the client.
> >
> > When I run server on PC and client on ARM board it works without any
> > problem.
> >
> > BUT if I run server on ARM board and client on PC, it works for some
> > time and
> > then the speed is drastically reduced. (I am sending 4k of data each
> > time.
> > after 50 sends it reduces its speed.  This happens always.)
> >
> > I did some debugging and found that after 50 sends, tcp_sendmsg() is not
> > being
> > called at the same frequency before slowdown.  Also when my driver
> > ether_tx seems to
> > be working fine.
> >
> > But still i am not able to get the reason for this behaviour.  Can
> > anyone give hints as to
> > why this is happening?
> >
> >
> > Regards
> > Jupe
> >
> > -- 
> >  Jupe
> >  jupejupe@rushpost.com
> >
> > -- 
> > http://www.fastmail.fm - mmm... Fastmail...
> 
> First, does your TCP/IP test application work okay on
> a Linux machine that does not use your new driver?
> 
> That's the first thing to test.
> 
> Next, is auto-negotiation working correctly in your
> driver? If you don't have auto-negotiation, have you
> set the Ethernet parameters correctly so that BOTH
> the server and the client use either full-duplex, or
> half-duplex, without mixing them up?
> 
> Next, make sure that you are properly handling
> transmit retries (handling all possible errors)
> in your driver. The transmitter does not want
> to drop packets if there is no room in the
> device, only the receiver should drop packets
> if there are no buffers. You do not want
> the TCP/IP replacement algorithm to request
> missing packets because this slows everything
> down. Again, in the transmitter section
> of your driver, consider data precious.
> 
> 
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips).
> My book : http://www.AbominableFirebug.com/
> _
> 
> 
> ****************************************************************
> The information transmitted in this message is confidential and may be
> privileged.  Any review, retransmission, dissemination, or other use of
> this information by persons or entities other than the intended recipient
> is prohibited.  If you are not the intended recipient, please notify
> Analogic Corporation immediately - by replying to this message or by
> sending an email to DeliveryErrors@analogic.com - and destroy all copies
> of this information, including any attachments, without reading or
> disclosing them.
> 
> Thank you.
-- 
  Jupe
  jupejupe@rushpost.com

-- 
http://www.fastmail.fm - Access all of your messages and folders
                          wherever you are