From owner-freebsd-hardware Mon Aug 25 08:34:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA18441 for hardware-outgoing; Mon, 25 Aug 1997 08:34:14 -0700 (PDT) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA18433 for ; Mon, 25 Aug 1997 08:34:12 -0700 (PDT) Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.7/8.6.10) id IAA24412; Mon, 25 Aug 1997 08:34:02 -0700 (PDT) Message-Id: <199708251534.IAA24412@passer.osg.gov.bc.ca> Received: from localhost(127.0.0.1), claiming to be "passer.osg.gov.bc.ca" via SMTP by localhost, id smtpdaaxCxa; Mon Aug 25 08:33:53 1997 Reply-to: cschuber@uumail.gov.bc.ca X-Mailer: MH X-Sender: cschuber To: Tom Samplonius cc: cy@uumail.gov.bc.ca, freebsd-hardware@freebsd.org Subject: Re: 3C509B Card In-reply-to: Your message of "Sat, 23 Aug 1997 12:49:16 PDT." Date: Mon, 25 Aug 1997 08:33:52 -0700 From: Cy Schubert - ITSD Open Systems Group Sender: owner-freebsd-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > On Sat, 23 Aug 1997, Cy Schubert wrote: > > > I think I got my answer from the 3Com website. > > > > Question: Can the EtherLink III family of adapters operate in promiscuous > > mode? > > > > Answer: All EtherLink III family adapters are certified for promiscuous > > mode. However, the parallel task feature of these adapters does not support > > the promiscuous mode since it drops the bad packets before it gets to the > > CPU. > > Not really. Most cards (all?) handle retransmits internally these days. > However, I don't belive the Etherlink driver is reading the count off the > card. Some of the other drivers use to report 0 for collisions as well, > until the driver was educated on where to read the collision count from. I had a chance to look at the driver and other drivers as well. You are indeed correct. The Linux driver does read the counts off the card whenever an interrupt from the card is generated. I think that this may be a bit of a waste of CPU, as the only time the count is needed is when it's displayed. I think that a system call could be used to get the information from the card instead of needlessly obtaining the information so that netstat could lseek() to a location in kmem to get it. After a little more thought, making the information available via the /proc filesystem might be a better idea. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it."