3com 3c509c-tpo problem ...

hello,

i recently got an old isa 3com 3c509b-tpo network adaptor for my 486 and
am having no end of problems trying to get it to work! there's tons of
info in google and i also consulted the latest kernel documentation,
still no joy. i was hoping that maybe an 'old hand' would have some
advice since apparently this was a pretty popular card in its day.

so far i've located the dos utility to change it from pnp to pnp
disabled, i've got some known values for io and irq that are confirmed
in /proc. i have it set to full-duplex (set on the dos utility and i use
the parameter, xcvr=12 for the module). i continually get a 'timeout
waiting for valid response from server'. my router is set to dhcp and
shows a half-duplex light for this connection. when i give the card an
ip and ping it, it works. i've changed it to half-duplex mode with the
same result. there are some other values that can be changed with the
dos utility that i haven't touched since they weren't mentioned in the
troubleshooting tips i'd read or were deemed irrelevant to solving this
problem.

any help would be appreciated,

thanks

Looks really strange - I have several 3c509b and all of them work fine with
3c509 module for many years already.
There is the kernel message when the module loads:
eth0: 3c5x9 found at 0x300, 10baseT port, address 00 20 af a6 97 c1, IRQ 5.
3c509.c:1.19b 08Nov2002 (E-Mail Removed)
http://www.scyld.com/network/3c509.html
eth1: 3c5x9 found at 0x310, 10baseT port, address 00 a0 24 74 6c ec, IRQ
10.
3c509.c:1.19b 08Nov2002 (E-Mail Removed)
http://www.scyld.com/network/3c509.html

Don't you have some cable problems, did you make cables or extend/connect
them? I do not really see what else I may suggest.
George.

weevil wrote:

> hello,
>
> i recently got an old isa 3com 3c509b-tpo network adaptor for my 486 and
> am having no end of problems trying to get it to work! there's tons of
> info in google and i also consulted the latest kernel documentation,
> still no joy. i was hoping that maybe an 'old hand' would have some
> advice since apparently this was a pretty popular card in its day.
>
> so far i've located the dos utility to change it from pnp to pnp
> disabled, i've got some known values for io and irq that are confirmed
> in /proc. i have it set to full-duplex (set on the dos utility and i use
> the parameter, xcvr=12 for the module). i continually get a 'timeout
> waiting for valid response from server'. my router is set to dhcp and
> shows a half-duplex light for this connection. when i give the card an
> ip and ping it, it works. i've changed it to half-duplex mode with the
> same result. there are some other values that can be changed with the
> dos utility that i haven't touched since they weren't mentioned in the
> troubleshooting tips i'd read or were deemed irrelevant to solving this
> problem.
>
> any help would be appreciated,
>
> thanks

On 2005-04-21, weevil <(E-Mail Removed)> wrote:
> hello,
>
> i recently got an old isa 3com 3c509b-tpo network adaptor for my 486 and
> am having no end of problems trying to get it to work! there's tons of
> info in google and i also consulted the latest kernel documentation,
> still no joy. i was hoping that maybe an 'old hand' would have some
> advice since apparently this was a pretty popular card in its day.
>
> so far i've located the dos utility to change it from pnp to pnp
> disabled, i've got some known values for io and irq that are confirmed
> in /proc. i have it set to full-duplex (set on the dos utility and i use
> the parameter, xcvr=12 for the module). i continually get a 'timeout
> waiting for valid response from server'. my router is set to dhcp and
> shows a half-duplex light for this connection. when i give the card an
> ip and ping it, it works.

Then maybe the card is OK and problem is with dhcp?
Anyway what is the reason to have a router with an address dynamically
changed?

Jarek P.

weevil wrote:
> hello,
>
> i recently got an old isa 3com 3c509b-tpo network adaptor for my 486 and
> am having no end of problems trying to get it to work! there's tons of
> info in google and i also consulted the latest kernel documentation,
> still no joy. i was hoping that maybe an 'old hand' would have some
> advice since apparently this was a pretty popular card in its day.
>
> so far i've located the dos utility to change it from pnp to pnp
> disabled, i've got some known values for io and irq that are confirmed
> in /proc. i have it set to full-duplex (set on the dos utility and i use
> the parameter, xcvr=12 for the module). i continually get a 'timeout
> waiting for valid response from server'. my router is set to dhcp and
> shows a half-duplex light for this connection. when i give the card an
> ip and ping it, it works. i've changed it to half-duplex mode with the
> same result. there are some other values that can be changed with the
> dos utility that i haven't touched since they weren't mentioned in the
> troubleshooting tips i'd read or were deemed irrelevant to solving this
> problem.
>
> any help would be appreciated,
>
> thanks

sorry, there's a typo in in the subject line - should say 3c509b-tpo.
yes this problem is frustrating since it seems from googling that a lot
of these cards work or experience some very strange problems - 1 of my
cards -tpo (rj45 only) came up in 'bnc'(coaxial,10base2) mode. this is
the 4th card i've used based on the 3c509b chipset and still no luck.
when i plug this line into my PIII sitting beside it with a D-Link pci
card everything works fine! i even disconnected the router and ran a
line straight from my dsl modem to the card and pppoe timed out.

the weird thing is as soon as i bought i stuck it in without checking
the settings and it worked before dying 5 minutes later during a
download. those settings were pnp. in either case, pnp or pnp-disabled,
it looks like the card is recognised properly, it just can't
communicate. does it have anything to do with box, old ibm aptiva.
doesn't look like there's anything relevant in the bios?

out of curiosity, can anyone translate this segment from the kernel docs
into lay english;

/////Extremely important caution concerning full-duplex mode/////
Understand that the 3c509B's hardware's full-duplex support is much more
limited than that provide by more modern network interface cards. Although
at the physical layer of the network it fully supports full-duplex
operation,
the card was designed before the current Ethernet auto-negotiation (N-way)
spec was written. This means that the 3c509B family ***cannot and will not
auto-negotiate a full-duplex connection with its link partner under any
circumstances, no matter how it is initialized***. If the full-duplex mode
of the 3c509B is enabled, its link partner will very likely need to be
independently _forced_ into full-duplex mode as well; otherwise various
nasty
failures will occur - at the very least, you'll see massive numbers of
packet
collisions. This is one of very rare circumstances where disabling auto-
negotiation and forcing the duplex mode of a network interface card or
switch
would ever be necessary or desirable.


by the way, i'm running slackware 10.1 with a 2.4.29 kernel if that's of
any importance. thanks.

By Thu, 21 Apr 2005 10:50:24 -0400, weevil <(E-Mail Removed)>
decided to post "Re: 3com 3c509c-tpo problem ..." to
comp.os.linux.networking:

>weevil wrote:
>> hello,
>>
>> i recently got an old isa 3com 3c509b-tpo network adaptor for my 486
<...>
>sorry, there's a typo in in the subject line - should say 3c509b-tpo.
<...>
>out of curiosity, can anyone translate this segment from the kernel docs
>into lay english;
>
> /////Extremely important caution concerning full-duplex mode/////
>Understand that the 3c509B's hardware's full-duplex support is much more
>limited than that provide by more modern network interface cards. Although
>at the physical layer of the network it fully supports full-duplex
>operation,
>the card was designed before the current Ethernet auto-negotiation (N-way)
>spec was written. This means that the 3c509B family ***cannot and will not
>auto-negotiate a full-duplex connection with its link partner under any
>circumstances, no matter how it is initialized***. If the full-duplex mode
>of the 3c509B is enabled, its link partner will very likely need to be
>independently _forced_ into full-duplex mode as well; otherwise various
>nasty
>failures will occur - at the very least, you'll see massive numbers of
>packet
>collisions. This is one of very rare circumstances where disabling auto-
>negotiation and forcing the duplex mode of a network interface card or
>switch
>would ever be necessary or desirable.

It sounds like if you want full duplex mode, it's known well enough to be
documented that you card is a 'bad player', and should be expected to
perform poorly if set to automatically negotiate this mode with another
node on the network, such as a autonegotiating switch, or another NI card.
Probably due to the design that precedes the applicable standard +/or poor
firmware or controller chipz. 3com has always considered itself a
'standard setter', and 'innovative'. Probably their cards of the same
revision work well enough with each other....


HTH,

/..

--

Life is fatal.
Stand clear of suspended loads.
Rhetoric is != intelligence, capability or performance.

/.. wrote:
> By Thu, 21 Apr 2005 10:50:24 -0400, weevil <(E-Mail Removed)>
> decided to post "Re: 3com 3c509c-tpo problem ..." to
> comp.os.linux.networking:
>
>
>>weevil wrote:
>>
>>>hello,
>>>
>>>i recently got an old isa 3com 3c509b-tpo network adaptor for my 486
>
> <...>
>
>>sorry, there's a typo in in the subject line - should say 3c509b-tpo.
>
> <...>
>
>>out of curiosity, can anyone translate this segment from the kernel docs
>>into lay english;
>>
>> /////Extremely important caution concerning full-duplex mode/////
>>Understand that the 3c509B's hardware's full-duplex support is much more
>>limited than that provide by more modern network interface cards. Although
>>at the physical layer of the network it fully supports full-duplex
>>operation,
>>the card was designed before the current Ethernet auto-negotiation (N-way)
>>spec was written. This means that the 3c509B family ***cannot and will not
>>auto-negotiate a full-duplex connection with its link partner under any
>>circumstances, no matter how it is initialized***. If the full-duplex mode
>>of the 3c509B is enabled, its link partner will very likely need to be
>>independently _forced_ into full-duplex mode as well; otherwise various
>>nasty
>>failures will occur - at the very least, you'll see massive numbers of
>>packet
>>collisions. This is one of very rare circumstances where disabling auto-
>>negotiation and forcing the duplex mode of a network interface card or
>>switch
>>would ever be necessary or desirable.
>
>
> It sounds like if you want full duplex mode, it's known well enough to be
> documented that you card is a 'bad player', and should be expected to
> perform poorly if set to automatically negotiate this mode with another
> node on the network, such as a autonegotiating switch, or another NI card.
> Probably due to the design that precedes the applicable standard +/or poor
> firmware or controller chipz. 3com has always considered itself a
> 'standard setter', and 'innovative'. Probably their cards of the same
> revision work well enough with each other....
>
>
> HTH,
>
> /..
>

addendum; i hate these solutions but i bought a rtl 8009 based isa card
(ne driver)and everything works fine! go figure!? total of 4 3c509 cards
i couldn't get to work!? thanks.

> It sounds like if you want full duplex mode, it's known well enough to be
> documented that you card is a 'bad player', and should be expected to
> perform poorly if set to automatically negotiate this mode with another
> node on the network, such as a autonegotiating switch, or another NI card.
> Probably due to the design that precedes the applicable standard +/or poor
> firmware or controller chipz. 3com has always considered itself a
> 'standard setter', and 'innovative'. Probably their cards of the same
> revision work well enough with each other....
>
>
> HTH,
>
> /..
>
Hello,

I had the same problem in my lab with the 3Com 3c905b. And I also replaced
them with Realtek chipset based cards. This works BETTER. The thing is that
if I put the line on high load in one direction, 100 percent of the packets
are received. If I do the same load in both dircections to the same time,
only about 85 percent of the packets are delivered. In theory on a full
duplex line, this should not be the case. I set the cards to:
speed 10 Mbit, duplex full, autonegation off (on both sides)
I used ethtool and mii-tool with the same results. I tried different Kernel
versions as well (2.6.7, 2.6.8, 2.6.10). So, whats really going on with
full duplex? I need 100 percent accuracy for my experiments. Do you have
any hint for me?

Thanks in advance, Alex