From owner-freebsd-net Wed Jan 19 19:32:25 2000 Delivered-To: freebsd-net@freebsd.org Received: from gto.networkphysics.com (DNS1.networkphysics.com [63.194.71.40]) by hub.freebsd.org (Postfix) with ESMTP id 7EA6315308 for ; Wed, 19 Jan 2000 19:32:22 -0800 (PST) (envelope-from pavel@hemi.networkphysics.com) Received: from hemi.networkphysics.com (hemi.networkphysics.com [10.1.0.30]) by gto.networkphysics.com (8.9.3/8.9.3) with ESMTP id TAA14147; Wed, 19 Jan 2000 19:32:22 -0800 (PST) (envelope-from pavel@hemi.networkphysics.com) Message-Id: <200001200332.TAA14147@gto.networkphysics.com> To: freebsd-net@FreeBSD.ORG Cc: Vinod Balakrishnan , Koos de Haan Subject: Re: de device driver problems with ZNYX 4 port 100mbps cards Reply-To: pavel@alum.mit.edu In-reply-to: Your message of "Wed, 19 Jan 2000 14:18:47 EST." Date: Wed, 19 Jan 2000 19:32:22 -0800 From: Tom Pavel Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>>>> On Wed, 19 Jan 2000, Vinod Balakrishnan 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: 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: 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 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