Re: 3c905C-TX [Fast Etherlink] problem ...
> 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 -= Oo.oO =- |=| [Ll] IPEX, s.r.o. "^" `o PGP signature
Re: 3c905C-TX [Fast Etherlink] problem ...
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 PGP signature
Re: 3c905C-TX [Fast Etherlink] problem ...
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 85ea status 000105ea > 1: @df659210 length 8296 status 00010296 > 2: @df659220 length 85ea 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3c905C-TX [Fast Etherlink] problem ...
> 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 -= Oo.oO =- |=| [Ll] IPEX, s.r.o. "^" `o PGP signature
Re: 3c905C-TX [Fast Etherlink] problem ...
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. - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3c905C-TX [Fast Etherlink] problem ...
> 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 -= Oo.oO =- |=| [Ll] IPEX, s.r.o. "^" `o PGP signature
Re: 3c905C-TX [Fast Etherlink] problem ...
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 [EMAIL PROTECTED] and we'll work on it. Thanks. - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
3c905C-TX [Fast Etherlink] problem ...
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 85ea status 000105ea 1: @df659210 length 8296 status 00010296 2: @df659220 length 85ea status 000105ea 3: @df659230 length 8296 status 00010296 4: @df659240 length 85ea status 000105ea 5: @df659250 length 85ea status 000105ea 6: @df659260 length 85ea status 000105ea 7: @df659270 length 85ea status 000105ea 8: @df659280 length 85ea status 000105ea 9: @df659290 length 85ea status 85ea 10: @df6592a0 length 8056 status 00010056 11: @df6592b0 length 805a status 0001005a 12: @df6592c0 length 85ea status 000105ea 13: @df6592d0 length 8296 status 00010296 14: @df6592e0 length 85ea status 000105ea 15: @df6592f0 length 829a 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 -= Oo.oO =- |=| [Ll] IPEX, s.r.o. "^" `o PGP signature
3c905C-TX [Fast Etherlink] problem ...
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 85ea status 000105ea 1: @df659210 length 8296 status 00010296 2: @df659220 length 85ea status 000105ea 3: @df659230 length 8296 status 00010296 4: @df659240 length 85ea status 000105ea 5: @df659250 length 85ea status 000105ea 6: @df659260 length 85ea status 000105ea 7: @df659270 length 85ea status 000105ea 8: @df659280 length 85ea status 000105ea 9: @df659290 length 85ea status 85ea 10: @df6592a0 length 8056 status 00010056 11: @df6592b0 length 805a status 0001005a 12: @df6592c0 length 85ea status 000105ea 13: @df6592d0 length 8296 status 00010296 14: @df6592e0 length 85ea status 000105ea 15: @df6592f0 length 829a 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 PGP signature
Re: 3c905C-TX [Fast Etherlink] problem ...
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 PGP signature
Re: 3c905C-TX [Fast Etherlink] problem ...
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. - - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3c905C-TX [Fast Etherlink] problem ...
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 PGP signature
Re: 3c905C-TX [Fast Etherlink] problem ...
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 85ea status 000105ea 1: @df659210 length 8296 status 00010296 2: @df659220 length 85ea 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
