Date: Wed, 19 Jan 2000 19:32:22 -0800 From: Tom Pavel <pavel@NetworkPhysics.COM> To: freebsd-net@FreeBSD.ORG Cc: Vinod Balakrishnan <vkb3q@cs.virginia.edu>, Koos de Haan <sdehaan@caiw.nl> Subject: Re: de device driver problems with ZNYX 4 port 100mbps cards Message-ID: <200001200332.TAA14147@gto.networkphysics.com> In-Reply-To: Your message of "Wed, 19 Jan 2000 14:18:47 EST." <Pine.GSO.4.05.10001191408100.1955-100000@cobra.cs.Virginia.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> On Wed, 19 Jan 2000, Vinod Balakrishnan <vkb3q@cs.virginia.edu> writes:
> I had posted a message a few weeks ago reporting some problems I have been
> facing with the ZNYX 4 port (100Mbps) cards used with the de device
> driver. And apparently I am not alone. Koos de Haan is also facing the
> same problems.
>
> It seems like the de device driver is unable to configure the znyx 4 port
> cards in 100Mbps full-duplex mode.
How timely. I too have been seing some half/full duplex problems with
my ZX346 cards under the de driver in 3.4-STABLE.
I'm trying to connect two machines with ZX346 cards back-to-back with
crossover cables. This sort of works when I "ifconfig media
10baseT/UTP" (say) both sides and avoid autonegotiation, but there
still appears to be a duplex mismatch since packets get lost when both
sides try to send a packet at the same time.
I've poked at this a bit, but I've just about reached the end of my
understanding. Here are some things that I have managed to learn:
1) The ZX344, ZX345, ZX346, and ZX351 cards are not probed with the
tulip_21140_znyx_zx34x_media_probe() routine, but instead are probed
with the generic tulip_2114x_media_probe() call. This is by design,
it seems (see lines 2167-2177 in if_de.c 1.93.2.3). I tried modifying
the driver to probe my ZX346 with tulip_21140_znyx_zx34x_media_probe(),
but this resulted resulted in an ethernet interface that would not
bring link up. I haven't tried to debug this further.
2) The generic tulip_2114x_media_probe() routine initializes only 2
ifmedias instead of the 4 ifmedias that
tulip_21140_znyx_zx34x_media_probe() does. These missing two are the
full-duplex variants of 10BaseT/UTP and 100BaseTX. This explains the
result reported by Vinod (that I also see):
> > > 2. ifconfig de3 mediaopt full-duplex , returns an error:
> > > ifconfig:SIOCSIFMEDIA: Device not configured
3) There is a minor bug that causes the boot messages to come out like:
Probing for devices on PCI bus 2:
de0: <Digital 21140A Fast Ethernet> rev 0x22 int a irq 10 on pci2.4.0
de0: ZNYX ZX34X 21140A [10-100Mb/s] pass 2.2
^^^
instead of:
Probing for devices on PCI bus 2:
de0: <Digital 21140A Fast Ethernet> rev 0x22 int a irq 10 on pci2.4.0
de0: ZNYX ZX346 21140A [10-100Mb/s] pass 2.2
^^^
In tulip_identify_znyx_nic(), there is code that reads an ID out of
the tulip_rombuf:
id = sc->tulip_rombuf[znyx_ptr + 5] + 256 * sc->tulip_rombuf[znyx_ptr + 4];
For me anyway, these IDs seem to be in the opposite byte order.
Perhaps this is a problem in porting the de driver from NetBSD. I
switched the code to:
id = sc->tulip_rombuf[znyx_ptr + 4] + 256 * sc->tulip_rombuf[znyx_ptr + 5];
and my ZX346 is now properly detected (although this only affects the
boot message).
4) With the generic tulip_2114x_media_probe() and my card plugged into
a hub, I don't see any data errors (i.e. everything is working fine).
However, the status is reported as not having the link up:
amx[1059] # ifconfig de1
de1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 10.2.0.5 netmask 0xffffff00 broadcast 10.2.0.255
ether 00:c0:95:e1:11:7d
media: 10baseT/UTP status: no carrier
supported media: autoselect 100baseTX 10baseT/UTP
5) I have tried the znb driver from ZNYX. It seemed to work fine and
had the full-duplex modes. But it didn't support BPF, which I need
for my test lab application. The Znyx folks promised me BPF support
in their next release.
So, where does that leave us? I'm not sure about the origins of the
code for setting up the ZX346 (etc.) boards, and why it uses the
generic tulip_2114x_media_probe() routine. It seems the history
involves 3 code repositories (FreeBSD, NetBSD, and Matt Thomas'
private version). Perhaps the ZX34[4-6] boards need to be initialized
differently from the ZX342 but more specifically than the generic
21140A. Anyone with any clues?
Also, any advice about how to probe what's going on in the
autonegotiation? If both sides of my crossover cable are defaulting
to half-duplex (as is my suspicion), then why am I getting packets
lost instead of collisions and backoff?
Thanks for any help.
Tom Pavel
Network Physics
pavel@networkphysics.com / pavel@alum.mit.edu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001200332.TAA14147>