3c905C-TX [Fast Etherlink] problem ...

3c905C-TX [Fast Etherlink] problem ...

[Robert Vojta]

[-- Attachment #1: Type: text/plain, Size: 1665 bytes --]

Hi,
  I have this card in intranet server and I'm very confused about very often
message in log like this:

eth0: Transmit error, Tx status register 82.
  Flags; bus-master 1, dirty 20979238(6) current 20979242(10)
  Transmit list 1f659290 vs. df659260.
  0: @df659200  length 800005ea status 000105ea
  1: @df659210  length 80000296 status 00010296
  2: @df659220  length 800005ea status 000105ea
  3: @df659230  length 80000296 status 00010296
  4: @df659240  length 800005ea status 000105ea
  5: @df659250  length 800005ea status 000105ea
  6: @df659260  length 800005ea status 000105ea
  7: @df659270  length 800005ea status 000105ea
  8: @df659280  length 800005ea status 000105ea
  9: @df659290  length 800005ea status 800005ea
  10: @df6592a0  length 80000056 status 00010056
  11: @df6592b0  length 8000005a status 0001005a
  12: @df6592c0  length 800005ea status 000105ea
  13: @df6592d0  length 80000296 status 00010296
  14: @df6592e0  length 800005ea status 000105ea
  15: @df6592f0  length 8000029a status 0001029a

  We have diskless machines and this is not a good thing, because when this
happens all traffic is stopped, all diskless machines are waiting and users
can't do nothing for several seconds (2-3 seconds). It's not critical, but
it's not comfortable. I tried another card, tried kernels 2.2.16, 2.2.19,
2.4.x series, change cable and still this problem. Any idea what may I do?

  .R.V.

Card is 00:12.0 Ethernet controller: 3Com Corporation 3c905C-TX
	[Fast Etherlink] (rev 74)

-- 
   _
  |-|  __      Robert Vojta <vojta-at-ipex.cz>          -= Oo.oO =-
  |=| [Ll]     IPEX, s.r.o.
  "^" ====`o

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: 3c905C-TX [Fast Etherlink] problem ...

[Andrew Morton]

Robert Vojta wrote:
> 
> Hi,
>   I have this card in intranet server and I'm very confused about very often
> message in log like this:
> 
> eth0: Transmit error, Tx status register 82.

This is a `transamit reclaim' error.  It is almost always
caused by this host being in half-duplex mode, and another
host on the network being in full-duplex mode.

It's a fairly common problem - I think I'll special-case
the error message...

Yu should check your network thoroughly, decide whether
you're supposed to be running half- or full-duplex.  Review
the vortex archives at http://www.scyld.com/mailman/listinfo/vortex

If that yields no joy, please send a report as described
in the final section of http://www.uow.edu.au/~andrewm/linux/vortex.txt
to vortex@scyld.com and we'll work on it.

Thanks.

-

Re: 3c905C-TX [Fast Etherlink] problem ...

[Robert Vojta]

[-- Attachment #1: Type: text/plain, Size: 584 bytes --]

> This is a `transamit reclaim' error.  It is almost always
> caused by this host being in half-duplex mode, and another
> host on the network being in full-duplex mode.

Hi,
  I tried to force this to be in fullduplex mode by options=0x204 (0x200 + 0x4)
and it works fine now. Please, can you send me some points to the documentation
where I can read more info about 'transamit reclaim' error and why this
happens, etc ...

Best regards,
  .R.V.

-- 
   _
  |-|  __      Robert Vojta <vojta-at-ipex.cz>          -= Oo.oO =-
  |=| [Ll]     IPEX, s.r.o.
  "^" ====`o

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: 3c905C-TX [Fast Etherlink] problem ...

[Andrew Morton]

Robert Vojta wrote:
> 
> > This is a `transamit reclaim' error.  It is almost always
> > caused by this host being in half-duplex mode, and another
> > host on the network being in full-duplex mode.
> 
> Hi,
>   I tried to force this to be in fullduplex mode by options=0x204 (0x200 + 0x4)
> and it works fine now.

mm..  It _should_ autonegotiate.  Perhaps the device at
the other end is old or not very good.

> Please, can you send me some points to the documentation
> where I can read more info about 'transamit reclaim' error and why this
> happens, etc ...

http://www.scyld.com/network/vortex.html is the official
place.  It doesn't tell you much.

vortex.txt has a pointer to 3com's documentation. Heavy
going.

When the NIC is running in full-duplex mode it *assumes*
that once (by default) 128 bytes of a frame have gone
onto the wire, the remainder of the frame will be sent
without any collisions.  This assumption allows it to reuse
part on the on-board memory - it transfers more data from
the host into the place where the currently-transmitting
frame used to reside.

If another host then comes along and generates a collision
this late into the frame, the NIC detects it but cannot
back off and retransmit the frame as it would normally do.
Because the frame's memory has been "reclaimed".  All it
can do is raise an interrupt and complain.

-

Re: 3c905C-TX [Fast Etherlink] problem ...

[Robert Vojta]

[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]

> mm..  It _should_ autonegotiate.  Perhaps the device at
> the other end is old or not very good.

Hi,
  it should but do not autonegotiating. All computers are connected to switch
CentreCOM FH716SW and there are several types of cards on this computers
like 3COM Tornado, 8139 chip, NE2000, etc.

> http://www.scyld.com/network/vortex.html is the official
> place.  It doesn't tell you much.
> 
> vortex.txt has a pointer to 3com's documentation. Heavy
> going.
> 
> When the NIC is running in full-duplex mode it *assumes*
> that once (by default) 128 bytes of a frame have gone
> onto the wire, the remainder of the frame will be sent
> without any collisions.  This assumption allows it to reuse
> part on the on-board memory - it transfers more data from
> the host into the place where the currently-transmitting
> frame used to reside.
> 
> If another host then comes along and generates a collision
> this late into the frame, the NIC detects it but cannot
> back off and retransmit the frame as it would normally do.
> Because the frame's memory has been "reclaimed".  All it
> can do is raise an interrupt and complain.

  Thanks for this informations ...

Best,
  .R.V.

-- 
   _
  |-|  __      Robert Vojta <vojta-at-ipex.cz>          -= Oo.oO =-
  |=| [Ll]     IPEX, s.r.o.
  "^" ====`o

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

3C905C and error e401 : problem solved

[francois.cami]

Hi Mr Morton and all linux-kernel,

I have been experimenting with the 3C905C, trying
to get rid of the annoying e401 error (too much work
in interrupt).

I've tried using 64 as max_interrupt_work 
and it solves completely
the e401 problem on this particular machine :

- yoda.rez-gif.supelec.fr (dns/proxy for 500 clients,
  on a 10Mbits/s direct Internet connexion, local
  network is 100Mbits/s)
	ASUS P2B-DS
	dual PII-350
	512MB RAM (2*128+1*256)
	3*IBM 18GB 10KT U2W SCSI 
	3C905C
	S3 Virge
Linux Slackware-current, 2.2.19 or 2.4.4 both built for smp
with APIC. 

Before setting max_interrupt_work at 64, the e401 error
could occur 20 times a day.
Now it doesn't occur anymore.

I have waited for a long time to test that on the
SMP PC because it is critical for our network.
I have tried to link these e401 messages with another
activity on the PC, like heavy I/O, to no avail. The
3C905C does 10 times as many interruptions as the SCSI
controller does. Lowering the max_interrupt_work creates
a lot more errors in the logs (all are e401).


On that second PC, the message still appears (very rarely though,
about once in two or three days. I cannot relate those
occurences to anything). It used to appear very often
(about 40 times a day).
I have tried to put the machine under stress (4 heavy FTP
transfers at once, each 400MB long, with 4 different
clients, connected in 100 MBits FD). The e401 message
has not appeared... I'm a bit at a loss here.

- lando.rez-gif.supelec.fr (FTP for the same network)
	ABIT LX6
	PII300
	128MB RAM
	IBM 8.4GB IDE (1st Master) 
         + Maxtor 60GB IDE (2nd Master)
	3C905C
	S3 Virge
Linux Slackware-current, 2.4.4, ProFTPD

All our network is 100MBits Full Duplex, switched
with 3COM switches.

Best regards, thanks for all your work

François Cami

Re: 3c905C-TX [Fast Etherlink] problem ...

[Wilfried Weissmann]

Robert Vojta wrote:
> 
> Hi,
>   I have this card in intranet server and I'm very confused about very often
> message in log like this:
> 
> eth0: Transmit error, Tx status register 82.
>   Flags; bus-master 1, dirty 20979238(6) current 20979242(10)
>   Transmit list 1f659290 vs. df659260.
>   0: @df659200  length 800005ea status 000105ea
>   1: @df659210  length 80000296 status 00010296
>   2: @df659220  length 800005ea status 000105ea
[snip]

Hi,

I had the same problem with 2.4.3-pre6 (also with the 3c905C). Alle
problems were gone with 2.4.4, so I stopped bothering. Hope this
helps...

Wilfried

Re: 3c905C-TX [Fast Etherlink] problem ...

[Robert Vojta]

[-- Attachment #1: Type: text/plain, Size: 519 bytes --]

> Hi,
> 
> I had the same problem with 2.4.3-pre6 (also with the 3c905C). Alle
> problems were gone with 2.4.4, so I stopped bothering. Hope this
> helps...

Hi,
  as I wrote in previous emails, I tried kernel 2.2.16, 2.2.19 and 2.4.x
series (means 2.4.1, 2.4.3, 2.4.4) and still this error. So, I must forced
my card to operate in full-duplex mode and errors gone.

Best,
  .R.V.

-- 
   _
  |-|  __      Robert Vojta <vojta-at-ipex.cz>          -= Oo.oO =-
  |=| [Ll]     IPEX, s.r.o.
  "^" ====`o

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]